Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7502 discussions

by Silver Rock

hallo, supose i´ve opened a sound with the wave module: >>> import wave >>> sound=wave.open(filename,'rb') now this is strange: >>> sound.getnframes() != len(sound.readframes(sound.getnframes()) True Why so? thanks in advance, Claire

18 years, 4 months

[linux-audio-dev] [ANN] JackMix 0.2 fresh on the shelfs

by Arnold Krille

taken from http://www.arnoldarts.de/drupal/?q=node/532 : "One step back, two ahead!" After almost two years of silence I managed to put together a new release of JackMix. The name explained: Comparing to jackmix:0.1.0 some experimental features are dropped. On the other hand this release is the first to use scons for the buildsystem and qt4 for the toolkit. Download and installation Download the source here: http://www.arnoldarts.de/drupal/files/downloads/jackmix/jackmix-0.2.tar.gz After unpacking (tar xzf jackmix-0.2.tar.gz && cd jackmix-0.2) call QTDIR=<path to your qt4-dir> scons configure to configure and afterwards call scons to compile the app. Calling scons install will install the binary in the chosen bin-directory but you will probably test JackMix before doing that... If your qt4 is installed in /usr/include/qt4 and /usr/lib/qt4 (as it is on gentoo) you need to add qtlibs=/usr/lib/qt4 to the configuration-command above. I will probably change/extend the qt-check in the future but for now this has to be used. Usage Be sure to have a jackd running, preferable via qjackctl which also has a nice window to connect inputs and outputs like the back of your rack. Next start jackmix. If all is well it will present you with a top-row of controls, a big matrix in the middle and some controls on the right. The top controls are the input gain, the right controls are output gain. The matrix in the middle controls the levels sent from the various inputs to the outputs. If you are tired of the simple potis for each channel and want easier mixing into stereo busses there is help available. Just select the potis you want replaced by using "Select" from the context menu of each control and then use "Replace" in the top-left control you want replaced. If all is working JackMix will choose the biggest possible replacing control (current available controls are mono-to-mono, mono-to-stereo and stereo-to-stereo). You can fill the empty places from the "Edit"-menu. Adding and removing of input- and output-channels is also done from the "Edit"-menu. Please note that if no jackd is running, JackMix will start but not show any controls. You can tell JackMix to create new channels, but nothing will happen. Restart JackMix after starting jackd and go on with your work. Changelog Changes since 0.1: -Using scons instead of autotools/make. -Using qt4 instead of qt3. -Dropped the potis borrowed from the kde-project. They where hard to port to qt4 and the ones from qjackctl are much nicer and where easier to port. - The ability to connect faders is dropped. For future releases this will be replaced by VCA-groups similar to bigger mixing-consoles. Have a nice week, Arnold -- visit http://www.arnoldarts.de/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern könnte, würde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen.

18 years, 4 months

[linux-audio-dev] [ANN] Aqualung 0.9beta7 released

by Tom Szilagyi

The authors are proud to announce the release of Aqualung 0.9beta7. Aqualung is an advanced music player originally targeted at GNU/Linux, today also running on other operating systems such as FreeBSD and MS Windows. We are striving to create one of the finest music players available, with respect to sound quality, stability, features and ease of use. This release is the latest in a series of beta releases on our way to the future stable release of Aqualung 1.0. It adds significant new functionality as well as important bugfixes. The ChangeLog for this release is listed below. Homepage: http://aqualung.sf.net Enjoy, Tom 2007-02-05 Tom Szilagyi <tszilagyi at users dot sourceforge dot net> * Aqualung 0.9beta7 http://aqualung.sf.net This release introduces important new features and bugfixes. Main reasons for upgrading: * CD Audio support, complete with CDDB, CD-Text, etc. You can play Audio CDs directly, or rip them to WAV, FLAC, Ogg Vorbis or MP3 (CBR/VBR, gapless via LAME) complete with tagging, on the fly. * Revamped Music Store Builder: better operation, greater flexibility. * Support FFmpeg library enabling the recognition of numerous formats e.g. AC3, AAC, WMA, WavPack, and the soundtrack of many video files. * Replaygain support for APEv2 tags. * Ability to set looping range when looping a single file. Should be useful for people playing along a recording, trying to learn phrases of a song. * Adding music to the playlist is now a non-blocking, interruptible background operation. * Drag-and-drop files from external sources (Nautilus, Konqueror, etc) into the Aqualung playlist. * Several critical memory leak fixes. * Numerous GUI refinements; fixed some rare bugs in engine, too. * Support for building against the new FLAC 1.1.3 API. * Aqualung operates correctly on bigendian systems (32 and 64 bit). * Running natively on MS Windows. A port of TAP-plugins is included in the installer. See http://aqualung.sf.net/win32 for more. NEW LIBRARY DEPENDENCIES: All of these are optional; Aqualung will build without them, disabling the functionality they provide. * libcdio >= 0.76 is required for CD audio support. http://www.gnu.org/software/libcdio/ * libvorbisenc for ripping into Ogg Vorbis. http://www.xiph.org/ogg/vorbis/ * libmp3lame for ripping into MP3. http://lame.sourceforge.net/

18 years, 5 months

[linux-audio-dev] [ANN] Releases : Tapeutape and Tranches

by Florent Berthaut

Hi everyone, I'm pleased to announce the release Tranches and Tapeutape. (my first release !!! ) Tapeutape is a midi-controlled virtual sampler.It is highly configurable,lets you create instruments/kits/setups and is designed for live performance.It works on Gnu/Linux with the jack sound server. There's a command-line and a gui version. It can be found at http://www.hitmuri.com/Tapeutape An example of what can be done with it : http://www.hitmuri.com/Tapeutape/demo_tapeutape.ogg Tranches is a midi-controlled multi-(inputs|outputs) live beat repeat|redirect tool for the jack sound server on Gnu/Linux !!! There's a command-line and a gui version. website : http://hitmuri.com/Tranches/ audio example : http://www.hitmuri.com/Tranches/demo_tranches.ogg Regards, Flo

18 years, 5 months

[linux-audio-dev] Sample Rate Conversion in Linux (Newby)

by Jonathan Ryshpan

Which algorithm/library/program is used for sample rate conversion by cdrecord in Linux? Other programs? I assume there is a library to perform this function, which is used by most utilities, xmms, amarok, cdrecord, audacity, etc. Is there any easy way to find this out? I have just done a simple test burning some sound recorded as a WAV file at 48,000 Hz to a CD (at 44,100 Hz of course), and think I have noticed a small reduction in quality. Thanks - jon

18 years, 5 months

[linux-audio-dev] freesound integration in Aldrin

by Leonard Ritter

In my quest to equip Aldrin with some serious collaboration features, I spent the past week adding support for The Freesound Project. http://www.leonard-ritter.com/freesound_integration (includes screenshots and sourcecode) -- Leonard Ritter -- Freelance Art & Logic -- http://www.leonard-ritter.com

18 years, 5 months

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

by Michael Ost

> On Tue, 2007-01-30 at 21:05 +0000, Bob Ham wrote: > Further to that, something constructive: perhaps you could try telling > your customers why *you* chose linux, rather than trying to find reasons > to tell them *they* should. My reasons, from back in about 2000, were "cost" and "interesting". First off the license costs were not hard to sell. And secondly that I personally wanted to program in Linux. I thought it would be interesting --- and it has been fun. Also the company was kind of a crapshoot and I wanted the professional experience on my resume if I needed to go get another job. Embedded Linux sounded good to me. I want to stick with Linux and hoped there were some measurable performance differences to tout. Sounds like there aren't, really. And now for some more kind of Dilbert-esque background for the curious... A couple of years ago, we tried answering this question by measuring the time between a midi impulse on a rigged midi cable and audio output on an oscilloscope. We tested Receptor vs Windows 2000 running VStack. The Receptor was not more responsive but was less jittery in its reponse. We engineers didn't feel that the results were carefully enough generated to be publicly announced, but we felt that our hunch was being confirmed. Then I made some perhaps loose comments about how Linux is less bloated than Windows. True, but not quantifiable. Then there is the general (and vague) perception among many in the music biz that Windows is not for pro audio. All of these factors led our non-tech people here to start saying that our OS was better. Being an engineer, and not being able to quantify "better", I would cringe when they would say that and qualify endlessly. But I also couldn't prove anything either way, so I kind of left it. As time has passed, I have found that I was naive about the costs of Wine (VST compatibility, Linux (hardware compatibility, especially USB and firewire audio/midi devices) and the costs of getting programmers productive on Linux as a development platform. Now it is time for a leap to a newer OS --- 2.4 isn't giving us SATA drive support and our Wine is getting old (vinegar? %). Our code could do Windows pretty easily. Should I push for that, or move to a newer Linux? There you have it. Life in the software business. By the way, I appreciate all of the comments. I expected it might be a loaded question! ... mo

18 years, 5 months

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

by Michael Ost

> "Frank Smith" <frsmith(a)gmail.com> > Nice point and this is the strength of OS. the problems are addressed > far quicker than in Prop' software. Yes, that's good. Microsoft doesn't give a hoot about professional audio. We can actually tweak the OS, and Wine, to improve performance of our specific application. We got an improvement of Wine's CRITICAL_SECTION implementation in (using futexes) that helped DFH perform during heavy use of a particular drum. - mo

18 years, 5 months

[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...?

18 years, 5 months

[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

18 years, 5 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