Linux-audio-dev December 2010

linux-audio-dev@lists.linuxaudio.org

65 participants
48 discussions

[OT] Richard Stallman warns against ChromeOS

by Victor Lazzarini

Stallman hitting the mainstream news: http://www.guardian.co.uk/technology/blog/2010/dec/14/chrome-os-richard-sta… Victor

14 years

Re: [LAD] [Jack-Devel] JACK and RT cgroups

by Dominique Michel

Le Thu, 16 Dec 2010 20:01:46 +0100, Dhaval Giani <dhaval.giani(a)gmail.com> a écrit : > On Thu, Dec 16, 2010 at 7:53 PM, Dominique Michel > <dominique.michel(a)vtxnet.ch> wrote: > > Le Wed, 15 Dec 2010 20:07:37 +0100, > > Dhaval Giani <dhaval.giani(a)gmail.com> a écrit : > > > >> > Turn about again, and i suggest that the jack/RT implications as > >> > part of "being fair to all, with no favourites' weren't given any > >> > consideration, or you wouldn't be here now. > >> > > >> > >> Someone made a noise, and so I knew about it. Not about jack being > >> a favourite. If projectX would have an issue, and I would be > >> informed, I would be equally willing to help them. I however would > >> not be in a position to keep a look at all projects out there and > >> what issues they would face if featureY came into existence. > >> > >> > I'm not throwing a tantrum, just staggered that something like > >> > this could happen in the first place. It just seems so obvious, > >> > as a logical process of feature construction, to consider wider > >> > implications, as you wrote, for all users, including chaps that > >> > use, and/or code for, jack/RT. > >> > > >> > >> Considering the fact that its only JACK facing issues (or at least > >> complaining), that too after two years of a feature being in > >> existence and after about a year for the default cgroup being > >> created, I think the decision was just fine. > > > > I am a non coding project administrator. My distro of choice is > > gentoo, so I am able to configure, compile and install a kernel. > > > > As such, I think than the less you can make is to add a text into > > the kernel help that address the fact that RT_GROUP_SCHED and > > CGROUPS will break any rt enabled software without expropriated > > setup, and that with a pointer to the documentation that will show > > how to do such a setup. > > > > I am still not seeing where RT_GROUP_SCHED and CGROUPS breaks any rt > enabled software. As has been repeated on this thread countless number > of times, there is *no* issue in the kernel. The issue is that by > default the userspace tools create a default group (I still hold to > the view that it is the right thing to do.). What is the point to install a kernel feature without the corresponding user space tools ? So, this is a kernel issue at the first place. And this must be documented into the kernel help. What is the point to install the user tools when its default configuration will break existing applications ? So, the second place to document it is into the user space tools, so that both casual users and distribution makers can make the right choice and configuration. > An application which uses > rt privileges is *special*. From a programmer view, yes. But from the user perspective, this is just an application among other applications. As project administrator, the documentation is one of my major preoccupation. If anyone can understand it, I am happy. If not, I make the needed changes it myself. > Either, > a) The application should make it much easier for the user to use this > capability (by for example creating the appropriate cgroups and so > on), so that it works out of the box or, > b) Inform the user what he needs to do very clearly and have the user > do the hard work. Many rt aware software was existing long ago cgroup and libcgroup. So, b) must be addressed at the first place : the cgroup kernel help (for advanced casual users) and into licgroup documentation. And also, distribution makers must be aware of their choices : by enabling new features that can break existing ones, they must understand that they have a hard work to do : make sure than their packages will work with each other, or they will be loosing users. > > What is being repeated again and again that making a one line change > to a configuration file is going to discourage new users. As I have > mentioned again and again, this has been in there for a few months > now, Most of the good applications cgroup and libcgroup are breaking has been into linux for years. > and if it were such a big deal, there would have been tons of bug > reports. Wrong, users are not fools, and before reporting bugs, they done some searching, or ask to some forum. Why do you thing they will issue bug reports when it is only some good working software that is not working anymore because of a miss-configured third party application ? > Also, this problem is going to come up again once systemd > comes into play. So it has to be fixed by the application as opposed > to people coming about and complaining how Linux developers are > totally against the jack community and are out to get them by making > such changes. Why do you want to force third party applications to adapt their code to your software when it is possible to 1) get ride of your software, 2) configure your software in a why the user can use its favorite application without problem ? Or do you gave a secret agenda where you want to make 1) impossible for every one and 2) impossible for normal users ? > > So, as has been done in the past in this thread, there are folks who > have stepped up to the challenge, and there are patches already > floating about. Instead of encouraging them, and supporting them (with > reviews and the like), instead folks are coming, repeating this > conspiracy theory. In one hand you say that it is easy to configure the user tolls, in the other hand, it is no documentation than a casual user can understand and follow. It is not a conspiration theory but a prod by the act: you are not willing to make your piece of software affordable for the casual user, and it will make life harder for them, as well than for the distribution makers. > > The only way to move forward is for rt applications to be aware that > Linux is different, and if you want your application to work out of > the box, some changes need to be made. I agree with you, but the first change to make are to the documentation of cgroup and its user tools. Again, why do you want to force to make changes to their code when this is not needed. > > This is my last post on non-technical issues in this thread. Do I need a special list ? the LAPA Linux Audio Project Administrator ? Why do you not explain what will be the benefit for a casual linux rt user of cgroup and libcgroup ? If you can do so and I find that it can be useful for the applications I am managing, I can and certainly will change my mind. As project administrator, the project documentation is one of my main concern. If I huge than anyone can understand it, I am happy. If not, I make the needed changes myself. Ciao, Dominique > > Dhaval -- "We have the heroes we deserve."

14 years

Meego pulseaudio "compliance" and "enforcement" (was Re: [Meego-handset] Enabling Speakerphone)

by Niels Mayer

On Tue, Dec 14, 2010 at 1:31 PM, Marco Ballesio > Please check here: > > http://meego.gitorious.org/maemo-multimedia/pulseaudio-policy-enforcement/t… > to get a few more hints on the subject. Hopefully there's more than just source-code to describe the policies and enforcement. Is there a design document stating the "organizational" or "legal" or "human" reasons for said policies and enforcements? And, as a developer, where is the documentation for the appropriate layer to use, the appropriate API, etc -- e.g. for the original question that started this thread -- how to switch on/off speakers, FM-radio transmitter, etc on handset. ( cf my original reply http://lists.meego.com/pipermail/meego-handset/2010-December/000066.html ) Something high-level like the following Maemo document would be very helpful -- but I have been unsuccessful finding such documentation for Meego: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Mu… Also, why not use ALSA use-case-manager: http://opensource.wolfsonmicro.com/node/14 UCM appears to be scheduled for other distros "handset" work: https://wiki.ubuntu.com/Specs/N/ARM/AlsaScenarioManager > the n900 Resource Policy enforcement points were directly interacting > with ALSA. As Krisztian pointed out, it's no more necessary (and at > the limit it may be dangerous for your system's health) to do so > within MeeGo, as the pulseaudio ports can elegantly handle the whole > thing. Potential to blow out my handset speakers duly noted (the n900 goes http://en.wikipedia.org/wiki/Up_to_eleven !), however, I wasn't advocating playing around with the ALSA layer indiscriminately, in fact, I specifically stated: > the "amixer" results of meego indicate an equally complicated > soundchip; where random hacking could render your system somewhat useless... is there documentation on all these values?: > http://nielsmayer.com/meego/n900-card0-amixer.txt . > The only chip mentioned by name is > http://focus.ti.com/lit/ds/symlink/tpa6130a2.pdf "TPA6130A2 Headphone" ................................ Regarding my old nemesis, pulseaudio ( http://tinyurl.com/2976vu6 == http://old.nabble.com/uninstall-pulseaudio-to-increase-audio-app-stability-… ), I think the only "elegant" thing about pulseaudio is that it's bluetooth handling works for those that care about bluetooth; given the number of bug-reports and incompatibilities pulseaudio generates in different distros, I'm not sure "elegant" is the right word.... >From my position, as a multimedia/ALSA/linux-audio developer, having to go through pulseaudio sounds like an all-around bad idea, and to have "enforcement" or "compliance" attached makes it sound even worse. Tell me it ain't so! There is a growing class of applications that do not want or need pulseaudio around -- those using http://jackaudio.org/ . When the jack audio server launches, the first thing it does it use dbus to disable pulseaudio. Is that also non compliant? It seems inappropriate to preclude an entire class of application -- real-time "pro" audio and video apps that utilize the Jack audio server to provide low-latency, tightly synchronized audio -- as needed for modern multimedia creation and playback. Perhaps such applications are a stretch for an OMAP3-class device, but given the many audio/media apps listed in http://omappedia.org/wiki/PEAP_Projects , clearly OMAP4 and beyond might not be, even on a puny "handset." Of course, those making such audio apps might sidestep pulseaudio compliance/latency/inefficiency issues by using http://opensoundcontrol.org/ and an external DAC ( http://gregsurges.com/tag/dac/ ). Finally, it seems odd that in a "handset" environment, pulseaudio is an absolute requirement. To me, it is just a waste of batteries, and a terrible source of unnecessary context switching and interrupts during audio playback. It's sort of like being forced to drive around in a gas-guzzling, oversized sport-utility vehicle with 10 foot tires and 5 feet of ground clearance -- just to drive to the market or work on a well-paved freeway on a summer's day -- even when one might prefer a bicycle, motorcycle, sports-car, subway, or whatever tool is best for the job. Given that's the argument against Java/Android on the handset (it's the SUV of languages/environments) it's unfortunate that lighter-weight and less monolithic and more "unixy" solutions aren't being pursued for audio on the Meego handset. Take for example HD audio/video playback -- something where you need a "sportscar" to get the latency and sample rate associated with the audio stream while also performing HD decoding (e.g. 16bit/96K audio is supported on omap3430 per http://and-developers.com/device_information ). Pulseaudio typically operates at a fixed rate and forces resampling to that rate, causing an oft perceptible loss in fidelity. So in order to allow "digital mixing" for notification signals or phone calls while watching an HD movie, either pulseaudio will be upmixing those signals to 16/96, which is inefficient for audio that doesn't need the higher bitrate; the alternative, which is what we get with pulseaudio, is that the DAC is running at 44 or 48k, and even though we might be listening to material at a higher sample-rate, it'll be resampled and sonic artefacts may be introduced in order to work with the 'lowest common denominator'. IMHO what is needed is not a "digital mixer" and resampler and extra user-space processing before going into the kernel and out to the sound hardware via ALSA drivers. We certainly need "use case management" and the notion of a digital patch bay, and some way of smoothly mixing between sounds, glitch free switching of sample rates at the ALSA level, and then choosing the direct path to hardware that'll best handle the "main audio task" we're doing -- e.g. playing music, watching a movie, making a phone call, or just using the screen UI. What isn't needed is "desktop networked audio" capabilities of pulseaudio, or any extra user-space streaming/mixing/resampling of signals. The inefficiencies introduced by pulseaudio is evidenced by the n900/meego-1.1 handset, which cannot maintain audio synchronization during audio or video playback if even the slightest trace of something else is going on, including a wireless network scan, or even just cursoring around in a networked terminal (which goes through the wireless stack in my setup). On Maemo/n900 note what happens when playing back an Mp3 -- pulseaudio consumes twice the resources at "high priority" of the decoding process: Mem: 239968K used, 5572K free, 0K shrd, 1856K buff, 68204K cached CPU: 31.5% usr 10.3% sys 0.0% nice 53.9% idle 4.1% io 0.0% irq 0.0% softirq Load average: 0.88 0.56 0.27 PID PPID USER STAT RSS %MEM %CPU COMMAND 781 1 pulse S < 3832 1.5 22.0 /usr/bin/pulseaudio --system --high-priority 1317 705 user S < 6320 2.5 12.2 /usr/bin/mafw-dbus-wrapper mafw-gst-renderer 971 1 user S < 1868 0.7 1.3 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session On Meego/n900, here's what playing track one in "Music player" looks like -- where even cursoring around on the command-line in bash in the terminal is enough to "desync" the audio stream for a few seconds -- and that's with pulseaudio running at nice=-11 and high priority! Note pulseaudio consumes 31.6% CPU while the decompression, presumably happening in bognor-regis "Media daemon and play queue manager" == 34.5% and finally the media player app itself at 6.7%.... all while consuming 21.3% memory just to play back an MP3.... top - 17:56:15 up 20 min, 1 user, load average: 3.31, 3.12, 2.07 Tasks: 106 total, 2 running, 103 sleeping, 0 stopped, 1 zombie Cpu(s): 18.1%us, 26.6%sy, 17.2%ni, 36.5%id, 1.2%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 226260k total, 215948k used, 10312k free, 84k buffers Swap: 786428k total, 5944k used, 780484k free, 81596k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1063 meego 20 0 127m 9m 7720 S 34.5 4 .5 1:35.09 bognor-regis-da 892 meego 9 -11 191m 4588 3256 S 31.6 2.0 2:45.14 pulseaudio 1104 meego 20 0 2364 960 744 R 10.5 0.4 0:00.22 top 1059 meego 25 5 91628 32m 29m R 6.7 14.8 0:29.26 meegomusic 803 root 20 0 38452 28m 17m S 3.8 12.8 0:38.55 Xorg 876 root 20 0 0 0 0 S 1.9 0.0 0:13.20 ipolldevd Here's *just* watching a video (big buck bunny 240p) on the meego handset -- and no audio is even playing back (constant triggering of desync bug seen when playing back audio stream?) but pulseaudio is working hard anyways, consuming almost 50% of CPU needed to decompress the video and audio stream: top - 17:46:48 up 11 min, 1 user, load average: 4.47, 2.20, 1.03 Tasks: 106 total, 2 running, 103 sleeping, 0 stopped, 1 zombie Cpu(s): 12.8%us, 31.9%sy, 55.2%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 226260k total, 222564k used, 3696k free, 100k buffers Swap: 786428k total, 1224k used, 785204k free, 85424k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1007 meego 25 5 269m 41m 32m R 59.3 18.9 1:27.18 meegovideo 892 meego 9 -11 191m 5272 3948 S 26.1 2.3 0:40.00 pulseaudio 803 root 20 0 33092 23m 13m S 4.1 10.6 0:10.83 Xorg I'm sure a simple experiment could determine exactly the "effect" of pulseaudio: Play the same playlist until the battery wears out using the same software player outputting first to pulseaudio (pref not through ALSA's pulseaudio driver because that wouldn't be "fair" to go through the kernel twice) then play the same through ALSA "dmix" interface, just to emulate pulseaudio's mixing/resampling functionality. I would imagine the pure-ALSA solution would pass the "energizer bunny' test for more hours and far fewer kernel/userspace context switches. Although a realtime userspace process like pulseaudio can help deliver stable audio in a multicore environment -- it may end starving out other processes on a slower uniprocessor. Which is why I believe a pulse-audio-free solution should be available and still be "compliant" on low-end systems. The one place where pulseaudio is currently helpful is in hooking up bluetooth devices. But ALSA has it's own bluetooth layer as well, and other architectures for audio shouldn't be precluded: http://bluetooth-alsa.sourceforge.net/future.html or Phonon (http://pulseaudio.org/wiki/KDE ). -- Niels http://nielsmayer.com

14 years

envy24control, resp. it's successor

by Ralf Mardorf

Pardon, I didn't follow the progress of envy24control. Did you finish the recently development and if so, where can we/I get the latest source code? Cheers! Ralf

14 years

Re: [LAD] envy24control, resp. it's successor

by Tim E. Real

(Repost, I replied to our MusE list!) On December 14, 2010 06:47:31 am David Santamauro wrote: > Hi Niels, > > > On Mon, 13 Sep 2010 17:36:11 -0700 > > Niels Mayer <nielsmayer(a)gmail.com> wrote: > > On Mon, Sep 13, 2010 at 2:25 PM, Ralf Mardorf > > > > <ralf.mardorf(a)alice-dsl.net> wrote: > > >Pardon, I didn't follow the progress of envy24control. Did you finish > > > the recently development and if so, where can we/I get the latest > > > source code? > > > > http:// mudita24.googlecode.com > > > > Status: still at 1.03. Waiting for Tim E. Real to commit and then will > > release 1.04. Or use Tim's current patches (see link above). I apologize, haven't had any time to complete the work. I did quietly commit once more later on I think (I hope?), un-announced. Its current state is my current state, there's nothing new to add right now. I was so worried that changing from hard-coded slider min/max and scale markings, to values obtained from asking ALSA, was the right thing to do. I felt it was, to support different, unknown, perhaps yet-to-be-sold cards. We had good discussions on the list about the issues and where it could go from here. Everyone contributed good points and a good understanding of its shortcomings and issues. Neils pointed out there's still some things to take care before we move on like some spacing issues, and of course we must deal with the meters, db markings, and slider height lining up correctly. Fons pointed out his card gives him an extra button below the first slider, for adjustable hardware input level, which kind of ruined the uniform look of the sliders. It works fine as is I think, but yeah, must continue with work on it. > > > > Niels > > http://nielsmayer.com > > ...quick question on the "Monitor PCMs" tab: Why are there 2 sliders > per PCM out? Shouldn't L/R Gang join channels 1 & 2, 3 & 4 etc... > Oh, is the gang not working? It was last I checked. Oh wait, maybe I see what you mean, replace the two sliders with only one, when gang is on? We talked about replacing this with a pan knob or slider, like the Windows version. So many good ideas came out, a good vision of what it could be, but it takes time to implement them. Tim. -------------------------------------------------------

14 years

Introducing ReverbTuner

by Sakari Bergen

Hi All, ReverbTuner is a program that uses AI to tune LV2 reverb parameters to match a convolution reverb. It's a school project made for an AI course, and is a rather quick hack. It's probably the lousiest ever LV2 host, and will crash with some plugins. However, the basic architecture should be rather good :) This has been at a standstill since March, so I thought I'd throw out the code for anyone who is interested. I've designed it to be as modular and scalable as possible, so using other plugin standards or distributing the computational load over a network should not be too hard. Also, the basic concept should work for any LTI effect, not only reverbs. More details (including build instructions) in the paper I wrote for school: http://beatwaves.net/files/software/reverbtuner/paper.pdf To build, you'll need: boost, SLV2, (a git version of) Aubio, Libsndfile, and Gtkmm for the UI the code can be checked out with svn from http://svn.beatwaves.net/svn/reverb_tuner/trunk Br, Sakari

14 years

LV2: Howto

by Harry Van Haaren

Hey all, A while ago I asked about LADSPA plugins, they're implemented & working smoothly now, thanks all that replied & Robin for the code! The next plugin I want to tackle is LV2, I've read lv2plug.in, and I understand how it works. I just don't have a clue where to start with implementing. Does anybody out there have some code lying about that just "bare-bones" loads the plugin? I've read the ZynJackU sources... but to no avail, they're too big for easy learning. Thanks for reading, -Harry

14 years

Re: [LAD] LV2: Howto

by Sakari Bergen

On 13.12.2010 11:25, Harry Van Haaren wrote: > Hey all, > > A while ago I asked about LADSPA plugins, they're implemented & > working smoothly now, > thanks all that replied & Robin for the code! > > The next plugin I want to tackle is LV2, I've read lv2plug.in > <http://lv2plug.in>, and I understand how it works. > > I just don't have a clue where to start with implementing. Does > anybody out there have > some code lying about that just "bare-bones" loads the plugin? > > I've read the ZynJackU sources... but to no avail, they're too big for > easy learning. > > Thanks for reading, -Harry If you grok C++, here is some wrapper code and a tutorial: http://www.nongnu.org/ll-plugins/lv2pftci/ -Sakari-

14 years

Update of zita-at1 (bugfix)

by fons＠kokkinizita.net

Zita-at1 has been updated to 0.2.1 fixing a nasty bug. Thanks to Oleg Ivanenko for reporting the problem and helping to solve it. As usual: <http://www.kokkinizita.net/linuxaudio/downloads> Ciao, -- FA There are three of them, and Alleline.

14 years

Interesting new functionality in Neil tracker

by Vytautas Jancauskas

Recently an option to allow easy resampling (in the tracker sense, not DSP sense) and a new pattern effect that allows you to generate and modify patterns using Python code has been added to Neil modular tracker. Enjoy, if you are in to that kind of thing. -- http://sites.google.com/site/neilsequencer/

14 years

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 2010