Linux-audio-dev July 2011

linux-audio-dev@lists.linuxaudio.org

66 participants
52 discussions

[LAD] [RME - hdsp] Multiface/Digiface/RPM detection

by Adrian Knoth

Hi! I've recently added support for the RME RPM to hdspmixer. Unfortunately, I don't have one, it's been done blindly with user feedback. This very user now reports that he needs to upload the device firmware from windows. I've checked hdsploader, and of course, it needs patching. I'll take care in a second. More surprisingly, though, the kernel wasn't able to upload the firmware itself, because it fails to detect the RPM and hence tries to upload a multiface firmware. After reading the kernel source, I think the code in hdsp.c is wrong: if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) { hdsp_write(hdsp, HDSP_control2Reg, HDSP_VERSION_BIT); hdsp_write(hdsp, HDSP_control2Reg, HDSP_S_LOAD); if (hdsp_fifo_wait(hdsp, 0, HDSP_SHORT_WAIT)) hdsp->io_type = RPM; else hdsp->io_type = Multiface; } else { hdsp->io_type = Digiface; } Who here owns a Digiface and can confirm or deny that the kernel correctly detects it as Digiface? Same for Multiface, though I guess since it's more or less the default, users wouldn't notice it. What's wrong with the code above? I think all occurrences of HDSP_control2Reg in hdsp_check_for_iobox need to be changed to HDSP_controlRegister and the second hdsp_fifo_wait needs to be inverted. But this is pure guesswork. If I come up with a patch, who here has a RPM, Digiface or Multiface to test it? TIA

14 years, 6 months

[LAD] Hardware audio decoder driver design

by Nikita V. Youshchenko

Hello. Soon I will work on a linux kernel driver for a custom audio decoder device that is being developed by a company I work for. If not going into details, that devices reads A52-encoded stream from system memory, and writes raw pcm stream to system memory. Simplest thing to do is - implement a character device, where user-space will write encoded stream, and from where user-space will read decoded stream. (driver for similar hardware, located at http://sourceforge.net/projects/vs10xx/, does that). However, perhaps a better architecture (e.g. in-kernel intergation with an audio sink) is possible? I'm looking for any related information - e.g. ideas on what interface to implement, examples of drivers for similar devices, etc. Thanks on any hints. Nikita Youshchenko, embedded linux developer.

14 years, 6 months

[LAD] GCC Vector extensions

by Maurizio De Cecco

I am playing around with GCC and Clang vector extensions, on Linux and Mac OS X, and i am getting some strange behaviour. I am working on jMax Phoenix, and its dsp engine, in its current state, is very memory bound; it is based on the aggregation of very small granularity operations, like vector sum or multiply, each of them executed independently from and to memory. I tried to implements all this 'primitive' operations using the vector types. On clang/MacOSX i get an impressive improvement in performance, around 4x on the operations, even just using the vector types for copying data; my impression is that the compiler use some kind of vector load/store instruction that properly use the available memory bandwidth, but unfortunately i do not know more about the x86 architecture. On gcc/Linux, (gcc 4.5.2) the same code produce a *slow down* of around 2.5x. Well, anybody have an idea of why ? I am actually running linux (Ubuntu 11.04) under a VMWare virtual machine, i do not know is this may have any implications. Thanks, Maurizio De Cecco

14 years, 6 months

[LAD] Suitable peak/RMS/etc. data for UI metering

by David Robillard

Hello, A new/upcoming LV2 extension (from Lars Luthman) includes facilities for sending host-calculated metric data for audio ports to a UI, for metering and such. This is intended as a sane replacement for the currently used kludge of having plugin control output ports provide this information. So, more DSP-minded folks, my question is: what data is required, and is a reasonable compromise between overhead and expressiveness? The current revision has the following: /** A data type that is used to pass peak and RMS values for a period of audio data at an input or output port to an UI, using port_event. See the documentation for pui:floatPeakRMS for details about how and when this should be done. */ typedef struct _LV2_PUI_Peak_RMS_Data { /** The start of the measurement period. This is just a running counter that must not be interpreted as any sort of global frame position. It should only be interpreted relative to the starts of other measurement periods in port_event() calls to the same plugin instance. This counter is allowed to overflow, in which case it should just wrap around. */ uint32_t period_start; /** The size of the measurement period, in the same units as period_start. */ uint32_t period_size; /** The peak value for the measurement period. This should be the maximal value for abs(sample) over all the samples in the period. */ float peak; /** The RMS value for the measurement period. This should be the root mean square value of the samples in the period, equivalent to sqrt((pow(sample1, 2) + pow(sample2, 2) + ... + pow(sampleN, 2)) / N) where N is period_size. */ float rms; } LV2_PUI_Peak_RMS_Data; Thanks, -dr

14 years, 6 months

[LAD] [ANN] TYOQA: Qtractor 0.5.0 - The Alpha Zulu awakening!

by Rui Nuno Capela

Howdy! TYOQA (the year of qtractor automation for the clueless) is now pretty real. I'd say it's all been my my prerogative, again and again, doing things my own way (do I hear Frank S. singing? nope. move along...). Is this the time to do the unthinkable? Should I tag it as beta now? Should I? There's one single reason for not doing so and a couple of others to make it through: 1. basically it's all the same functionality that stays put or improved in a few spots; 2. it just feels like it! :) Now comes the mighty corrosive one: I'll be off on vacation soon. Summer is waiting for me. And I just hate to miss that kind of deadline. Woohoo! Is there anything else to mention? Go ahead, make your day: Qtractor 0.5.0 (alpha zulu) is now released! Release highlights: * TYOQA! Audio/MIDI track and plugin parameter automation (NEW) * MIDI controller catch-up behavior (NEW) * All zooming in/out relative to views center (NEW) * Audio gain/panning smoothing changes (FIX) Happy summer 2 y'all! Website: http://qtractor.sourceforge.net Project page: http://sourceforge.net/projects/qtractor Downloads: - source tarball: http://downloads.sourceforge.net/qtractor/qtractor-0.5.0.tar.gz - source package (openSUSE 11.4): http://downloads.sourceforge.net/qtractor/qtractor-0.5.0-3.rncbc.suse114.sr… - binary packages (openSUSE 11.4): http://downloads.sourceforge.net/qtractor/qtractor-0.5.0-3.rncbc.suse114.i5… http://downloads.sourceforge.net/qtractor/qtractor-0.5.0-3.rncbc.suse114.x8… - from the dusty shelf: user manual (anyone?): http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf Weblog (upstream support): http://www.rncbc.org License: Qtractor is free, open-source software, distributed under the terms of the GNU General Public License (GPL) version 2 or later. Change-log: - MIDI controller learn/catch-up sees the way in: MIDI controller changes are now only effective after catching-up with their respective program parameters, avoiding abrupt jumps and keeping a safe and continuous behavior. - Track/Height menu is now featured, giving access to Increase, Decrease or Reset the current track height. - All changes to audio gain and panning on tracks and buses are now applied following a piece-wise linear ramp, reducing the old nasty clicks, pops or zipper artifacts that might be awfully audible on some situations, most specially on automation. - All zooming in/out is now relative to either the viewport center or current mouse cursor position if found laying inside. - TYOQA! the underground sources have emerged:... after years in the making, track automation, or dynamic curves as some like to call, is finally a reality, tricky but real ;) - Audio clip anti-glitch/ramp-smoothing effect is now slightly independent of current buffer-size period (mitigating bug #3338113 effect). - Once buried under the Edit menu, Clip menu has been finally promoted to top main menu. - Debugging stacktrace now applies to all working threads. - Fixed muted loop playback on audio clips ending coincidentally with the loop-turn/end point. - Old/deprecated JACK port latency support added to audio recording latency compensation. - Audio clip merge/export lock-ups now untangled (fixes bug #3308998). - LV2 extension headers update. - Fixed configure of newer LV2 host implementation stack (LILV) when older (SLV2) is not present. Enjoy && Cheers! -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

14 years, 6 months

[LAD] Fwd: lv2 extension bugs

by Lieven Moors

---------- Forwarded message ---------- From: Lieven Moors <lievenmoors(a)gmail.com> Date: Mon, Jul 25, 2011 at 12:55 PM Subject: Re: [LAD] lv2 extension bugs To: David Robillard <d(a)drobilla.net> On Sat, Jul 23, 2011 at 10:46 PM, David Robillard <d(a)drobilla.net> wrote: > On Sat, 2011-07-23 at 21:22 +0200, Lieven Moors wrote: > > On Sat, Jul 23, 2011 at 09:10:42PM +0200, Lieven Moors wrote: > > > On Sat, Jul 23, 2011 at 02:19:39PM -0400, David Robillard wrote: > > > > On Sat, 2011-07-23 at 17:53 +0200, Lieven Moors wrote: > > > > > On Sat, Jul 23, 2011 at 10:23:13AM -0500, Gabriel Beddingfield > wrote: > [...] > > Since I'm not even sure it is a bug > > in an LV2 extension, I might be forgiven > > to post it here. > > > > It's a problem you run into when you > > try to configure one of the drobilla > > packages (I think it's flowcanvas). > > ... Well, this thread was pretty silly. If it's a problem with building > my repository, hosted at drobilla.net, then yes, file bugs there :P > > (Though it's certainly not flowcanvas, which has nothing whatsoever to > do with LV2) > > > Configure fails, says that ext/event/event-helpers.h > > cannot be found, even though it's there. > > After scratching my head for a while, > > I found out it's the waf test that is > > failing. > > > > On Harry Haaren's blog I found the > > answer. > > > > modify line 28 in event-helpers.h > > by removing http from the address. > > Line 28 in event-helpers.h is an include line that does not contain > "http" anywhere: > > http://lv2plug.in/repo/trunk/ext/event.lv2/event-helpers.h > > The same is true of the version in the latest release of that extension: > > http://lv2plug.in/spec/lv2-event-1.2.tar.bz2 > > > OK, what happened was that I landed on the http://lv2plug.in/ns/ext page, was expecting a download extensions link, didn't find it, and downloaded the files manually from the links on those pages. sorry for all the fuzz... greetings, lieven

14 years, 6 months

Re: [LAD] GCC Vector extensions

by Stéphane Letz

> > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Jul 2011 12:04:06 +0200 > From: Maurizio De Cecco <jmax(a)dececco.name> > Subject: Re: [LAD] GCC Vector extensions > Cc: linux-audio-dev(a)lists.linuxaudio.org > Message-ID: <4E2D3F96.2010206(a)dececco.name> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Short resume of my initial post: i found that using the gcc vector > extensions induced a 2x slow down using gcc, and a 4x speed up in clang. > > I made more tests, isolating a small code example, on Mac OS and Ubuntu, > and i found out the origin of the problem, even if i do not know what > exactly happening. > > My original test used vectors of float of size 8; the gcc vector > extension documentation says that if the vector size do not match the > hardware vector size, the code is synthesized in some way. > > With a vector size of 8 i found the above results under Mac OS X, using > clang and gcc4.2, and under Ubuntu 11.04, using clang and gcc4.5.2. > > When i move to a vector size of 4, things go better; clang slow down wrt > the size of 8 of around 2x, and gcc obtains the same result; the > interesting point is that gcc obtains essentially the same speed with > and without vector extensions, meaning probably that the compiler is > good enough in vectorizing the code, at least in the the test cases i used. > > I include the code, results and scripts to run the tests in a small zip > if anybody want to make other tests; the test code compute an arbitrary > vector computation (essentially 100 million multiply add), starting from > a seed given as argument. > > The code is modeled around the way jmax compute, i.e. one vector > operation at a time on vectors passed by pointers, and it is not > designed to be the fastest possible code to implements this computation. > > Thanks for the help, > > Maurizio You should really give the produced assembly code in each test case. Stephane

14 years, 6 months

[LAD] [LAA] [ANN] release gxtuner-1.0

by hermann

Hello I like to announce the first release of gxtuner, a simple, small and lightweight guitar/bass tuner for jack. gxtuner comes with a analogue like interface (scale), show the tune (char) and the accumulated frequency (Hz) and is licensed under the GPL. It's a break out of the guitarix tuner module, you can download it here: http://sourceforge.net/projects/guitarix/files/gxtuner/gxtuner-1.0.tar.bz2/… have fun hermann

14 years, 6 months

[LAD] remove snd dummy

by Christoph Kuhr

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, i compiled the alsa sources with the dummy otion, now finished using it, how do i get rid of it? i tried to compile the sources without the dummy otion, but it didnt work. (perhapes with an ice1724 option?) i completley removed the alsa packages and reinstalled them without any effort. lsmod doesnt show any snd module... im using natty with lowlatency kernel (11.04 + 2.6.38lowlatency) and an ice1724 chip thanks in advance regards Ck - -- PGP Key ID 0x528422c1; PGP Public Key / PGP Key verification: pgp.mit.edu pgp.zdv.uni-mainz.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJ/OKAAoJEBra75lShCLBUgoIALVE0FCz+VCgAr4XelbbMENV w355Ckvhu0oYAtx2fGqcbKZoFM2IDnXCC7RXXsiX+EyYv9kAy/E5fRFcYbzXN6Kp Qgt08nUJvdrX2GlVeuWpvCDYP4RY8cjhk0lHyWFIKc88jKCvB/OB+LvPTQPdcN++ 85FEeS6mYGZJupIy2mMLFivLIYH0jdG8VMb4B+fxchBMCNMqfPRCYilK0uC6RwZ5 2gFdS2rb/MTj3lC5r2cU10x6zM9tB4CpnGz11mleN9RlKA2EtV/myKDBn58TXcUq tNDLMeqyahH5JB1ACKMuBA4iYEs+z65ASaH/0bU1BgSSEVoaACKmtykRkequ6cQ= =HJAx -----END PGP SIGNATURE-----

14 years, 6 months

[LAD] Alan Ernest "Cal" Calvert dies at 61

by Gabriel Beddingfield

Friends: Cal, the lead developer of Yoshimi, passed away on July 2 in Victoria, Australia. http://tributes.couriermail.com.au/obituaries/couriermail-au/obituary.aspx?… While this was not unexpected, we're all very sad to see him go. I'm doubt that his family has any idea what he meant to us. If anyone has an idea on how we can show our appreciation, please share it. -gabriel

14 years, 6 months

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 July 2011