Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

2 participants
7534 discussions

[linux-audio-dev] Old hat - comparison against windows

by Michael Ost

Can anyone suggest ways to compare audio/midi performance between Linux and Windows that (1) are relevant to non-technical musicians and (2) make Linux compare favorably? Not things like "I just don't like Windows" or software feature comparisons or the politics of open vs. closed source, but rather things like responsiveness to audio interrupts, RAM footprint of the OS and ...? I work for a company that sells a Linux based piece of hardware that plays windows VSTs. We spend alot of time on compatibility, especially on getting the plugins to work with Wine. I often get asked about switching to Windows and I don't have a good answer. My sense is that the main benefit of Linux is that audio interrupts are serviced faster and more predictably than in Windows because of SCHED_FIFO and Linux's low overhead. And clearly musicians could feel that, especially at lower buffer size settings so that's the kind of thing that could matter. But is it _really_ true? Is there a standard way to measure it? Or published results about it? Are there any other things to compare? Thanks for any input. I _want_ to believe! %) ... mo PS: apologies for any confusion that comes from posting to both linux-dev and linux-user. I wasn't sure which list this is more appropriate to...?

19 years

[linux-audio-dev] LADSPA needs & wishes

by Fraser

Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. Let me show what I mean with a few examples. I have a control that represents a gain knob (say -12dB -> 12dB): What's best for the run function is a value that represents the ratio which I can simply multiply the audio by as it it keeps the maths simple (0.25 -> 4). What's best for display is decibels (as that is way gain is understood). I can't do this with LADSPA - so as I programmer I'm left with a lose-lose choice. * I either choose a parameter range of -12 -> 12 (dB) and convert that to a ratio every time the run function is called: fGain = pow(10, *(psMyPlugin->m_pfControlGain) /20); Which is an unnecessary use of cpu. (and as someone who has mixed many albums on computers you need every scap of cpu you can get) * Or I choose to use 0.25 -> 4 as my range. Now users are faced with a parameter they don't intuitively understand (it is contrary to every other bit of audio gear they have ever used) - most people cannot do 20*Log10(Gain) in their heads to work out the equivalent value in dB. Of the two choices I choose the first, better to eat up too much cpu than to have an interface that is unintuitive, but this is not ideal. This gets worse when you have a control for something like 'warmth'. The user does not need to know the range of values required to apply warmth in an efficient manner (it won't mean anything to them), they just need to know how much (0%-100%). Another example - presets I have a control that allows an operator to chose one of fifty presets (say a reverb with small room, medium room, large room, hall etc). I don't have a choice this time. Internally using an integer to represent the different presets is fine, it's exactly all I need. However even though I know what the preset is, I cannot display it's name back to the user, so our user is left with a set of meaningless numbers which they must resolve into names by some other means (print the doco out and stick it on the wall?) What I'd find useful in the api is an optional 'get_display' function which allows the host app to get a human interpretation of a parameter for display. It would only need to be called when a plugin windows is opened or when a parameter is changed. Since the host has to convert the parameter to a string in order to display it anyway, this is not a extra step overall. We are just bringing it into the realm of the plugin. /* pseudo code */ void GetMyDisplay(char *stDisplay, int Size, unsigned long Port) { stTemp[LADSPA_MAX_EVER_DISPLAY_SIZE); switch(Port) { case MY_GAINCONTROL: sprintf(stTemp,"%4.1f dB",20*log10(PortValue)); stTemp[Size-1]='\0'; /* truncate it to what the host wants*/ strncopy(stDisplay,stTemp,Size); break; case MY_WARMTHCONTROL: sprintf(stTemp,"%4.1f %%",some_complex_function(PortValue)); stTemp[Size-1]='\0'; /* truncate it to what the host wants*/ strncopy(stDisplay,stTemp,Size); break; } } Now for a wish. GUI - under OSX or windows this isn't such a big drama, there's only one GUI environment to deal with. under Linux it's a different matter. I sometimes think the best thing to do is to provide enough hints to the host so it can render a more comprehensive gui, if it desires, rather than the plugin drawing the gui as is traditionally done. This would entail a few things. 1) Utilize ports of type: LADSPA_PORT_OUTPUT | LADSPA_PORT_CONTROL what is that? -> it's a meter, a light, etc We'd just need some hints defined and the rest is up to the host (most host apps already have their own audio specific widgets. we just need to tell them which ones we want to use). These all need to be bounded as any other control would be. /* a peak meter, expects a ratio not a dB value */ LADSPA_HINT_METER_PEAK /* a vu meter, expects a ratio not a dB value */ LADSPA_HINT_METER_VU /* Some meters like gain reduction meters in a compressor meter backwards, ie illuminated from max value downwards rather than minimum value upwards */ LADSPA_HINT_METER_REVERSED /* a simple on/off light */ LADSPA_HINT_LIGHT_ONOFF /* a light which has intesity */ LADSPA_HINT_LIGHT_INTENSITY 2) Add control layout to the port definitions Could be done as by defining arbitrary bounding boxes. /* * +----------+------+ * | gain | | * +----------+ meter| * | warmth | | * +----------+------+ */ PortLayoutHints[MY_GAIN].top=0; PortLayoutHints[MY_GAIN].bot=1; PortLayoutHints[MY_GAIN].left=0; PortLayoutHints[MY_GAIN].right=3; PortLayoutHints[MY_WARMTH].top=1; PortLayoutHints[MY_WARMTH].bot=2; PortLayoutHints[MY_WARMTH].left=0; PortLayoutHints[MY_WARMTH].right=3; PortLayoutHints[MY_METER].top=0; PortLayoutHints[MY_METER].bot=2; PortLayoutHints[MY_METER].left=3; PortLayoutHints[MY_METER].right=5; 3) Customization - control colours in the layout hints - background & logo images in the descriptor etc This would all be optional for the host Thanks for taking the time to read though all this, turned out to be longer than I anticipated! regards, Fraser

19 years

[linux-audio-dev] Usb audio problem

by Bharat Singh GUSAIN

Hi all, I am trying to record audio from my STM webcam the driver for it's sound card's driver is loaded automatically as snd-usb-audio. But When I try to record through sound recorder, it did't record anything. On seeing at the catc traces I came to know that the sound recorder even don't set the streaming alternates. Any suggestions? Best Regards ---- Bharat Singh Gusain ST Microelectronics HPC/PMG-Imaging RD&I Plot no-1, Knowledge Park III Greater Noida - 201308, India Mobile - 9911121667 PSTN: 0120-4003414 PH: 0120-2352999 EXTN: 2772 www.st.com

19 years

[linux-audio-dev] Sound processing plugins' crashes

by Stefano D'Angelo

Hi, maybe it's just another of my dumb questions, however I would like to know whether it is happened to you that a sound processing plugin (LADSPA, LV2, VST, etc.) crashed (segm. faults, etc.). In such case, can you estimate how often does it happen that such plugins are misprogrammed? Thanks in advance, Stefano

19 years

[linux-audio-dev] Apologies (was: Re: an relevant link about Vista)

by Marc-Olivier Barre

On 1/25/07, Carlo Capocasa <capocasa(a)gmx.net> wrote: > > We need more moderators on the list, mail me ;-) > > Hey ho, thought police! Let us all think right and be right and have > someone else decide on what that 'right' actually means! > > What I'm getting at is, you have absolutely no way of knowing whether or > not Israel actually is an Apartheid state, or how that might or might > not be relevant to this list. > > What's with the people who might want to write a song about Israel > and/or Apartheid? Oh right, that's not important, we have more important > things to do, we are all about National Security, and stray thinkers are > a danger, so we must silence them with whatever means necessary to us. > > So in come the moderators and you have to watch your step around here > before you say anything about Jews or you get busted. > > Now personally I couldn't give a bit more about what Jews aren't or are > doing, but it seems every time you mention them everybody goes nuts. > What goes? What's REALLY behind this? > > Carlo > > I think I own everyone an apology for being part of all the fuss that has been going on the list for a few days now. When I wrote the above quoted sentence I did not imagine the (disproportionate) consequences this would have, and more importantly never intended to imply that a moderator was here to control if what was said on the list was right or wrong thinking. Although I do think that as a moderator and administrator myself I need to make sure a certain ethic is respected, the best way to deal with the original problematic message was just to ignore it, since the replies only caused a flame war. Concerning the need to decrease the work load of moderating the list, I propose another approach : As discussed previously on the list, we will certainly move to linuxaudio.org. Let's use this opportunity to tune mailman to our needs. There are not so much actual message that fall into the 'in-need-of-moderation' category. There are two actually : non-member messages and HTML messages. The biggest part of the job is to filter 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, and also to be able to feed spamassassin with new spam samples directly from the moderation page. If you are willing to help, if you know of an existing solution or if you happen to have ideas concerning this, please, drop me an email. It is as of this momment the best way to help, and is the first step towards making moderation faster for every one. Again accept all my appologies. __________________ Marc-Olivier Barre, Markinoko.

19 years

[linux-audio-dev] Cannot boot 64Studio from SATA frive

by Frank Smith

HI Just wondering if this will get through from my Gmail act. I have loaded 64studio onto my only new SATA drive and now cannot boot at all ( black screen cursor only) Anyone any idea how I goot the machine? Or do I need to reinstall it all again. ( It did ask to install grub to the MBR and I said yes) Many thanks Bob wavesound

19 years

[linux-audio-dev] an relevant link about Vista

by Dave Phillips

Greetings: This link may have been posted here before now, but it bears repetition : http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt Nasty stuff planned in Redmond. Best, dp

19 years

Re: [linux-audio-dev] JACK data transfers

by danni

On a side note there is a discussion on the freebob list of whether to add a control api to Jack or just for freebob. On Thursday 25 January 2007 04:40, linux-audio-dev-request(a)music.columbia.edu wrote: > On 24 Jan 2007, at 16:02, Stefano D'Angelo wrote: > > Well... I know I'm quite a boring person, but I need some informations > > for my project and so I'm going to stress you a bit ;-) > > I'm wondering if JACK is suitable to transfer non-audio data beetween > > applications (my particular case is to transfer control data to > > processing plugins). Is that "naturally" possible, is it an hack or is > > it impossible at all? > > You could encode control data in the audio stream, or build a bespoke > JACK that add additional data types, or you could use the nascent > JACK-MIDI stuff. > > You could also look at OSC, which, depending on your syncronisation > needs could be a better fit. > > > And another thing (I'm too lazy to check it out myself :-P): does jack > > transfers data by copying or uses something like shared memory or > > whatever? > > It uses shared memory where possible. > > - Steve -- When it comes to broken marriages most husbands will split the blame -- half his wife's fault, and half her mother's.

19 years

[linux-audio-dev] Sound processing objects architecture, is it possible?

by Stefano D'Angelo

Hi all, I'm quite new to sound-related programming, but however I have an idea which could interest some of you, but I don't know if it's possible to develop such thing. What I'd like to work on is a sound processing architecture (LADSPA, VST, DSSI, etc.) wrapper, which hides the details of a particular implementation to audio program developers. The whole thing could be made of a library to be used directly by audio developers in their programs, one or more configuration files used to retrieve directories in which plugins are placed and other stuff, and modules which contain implementation details for each processing architecture. The library could also contain some code to "trap" particular kinds of functions (for example Xlib functions to embed plugin GUIs inside programs). I think that the advantage of all of these stuff is to enable programs to use any kind of processing object (they could not only be loadable modules, but also text files or whatever), to collect "information" on how to implement a certain processing object type just in one place, and, last but not least, to ease creation of new standards and comparison of existing ones. What do you think about it? Sincerely, Stefano D'Angelo

19 years

[linux-audio-dev] a new patent for us to challenge

by Paul Davis

http://www.freshpatents.com/Low-latency-real-time-audio-streaming-dt2006040… in which Microsoft patents designs partially implemented by OSS 10 years ago and fully implemented by ALSA 5 years ago. Wrapping this up in windows API nonsense obscures the basic fact this design is not innovative in any way unless compared only to existing Windows audio driver architectures.

19 years

Jump to page:

2026

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