[LAD] Re: Pitch estimation
Le Thu, 25 Apr 2024 11:45:20 +0200, Fons Adriaensen a écrit : > Hello all, > Fons, Sorry for my preceding question, I should have read the zita-at1 description on your website before asking. Into it, it is stated that the pitch information used is 10 ms older than the signal it is applied to. Which is amazing because, with A=440 Hz, the low E of a guitar is at 82 Hz, which is a period of 12.2 ms. And when tuned in drop C tuning, that low C is at 65 Hz, which correspond to 15.38 ms. Now I must go out, but I will try in the evening. All the best, Dominique ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Pitch estimation
Le Thu, 25 Apr 2024 11:45:20 +0200, Fons Adriaensen a écrit : > Hello all, Hello Fons, > The basic method is to look at the autocorrelation > of the signal. This is a measure of how similar a > signal is to a time-shifted version of itself. It > can be computed efficiently as the inverse FFT of > the power spectrum. > This a test of the pitch detection algorithm used in > zita-at1. > > The X-axis is time in seconds, a new pitch estimate is > made every 10.667 ms (512 samples at 48 kHz). > > Vertically we have autocorrelation, the Y-axis is in > samples. Red is positive, blue negative. The green dots > are the detected pitch period, zero means unvoiced. > The blue line on top is signal level in dB. From the start of a note, do You know how long it takes, or how much periods of the signal it takes, in order to get the pitch? Best, Dominique ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Cal Big Styles 1.0.0: Initial release
Hi, I was frustrated by the font sizes in Calf when used with a high resolution screen. So, I made new styles with bigger font sizes and I put them on github. https://github.com/domichel/calf_big_styles https://github.com/domichel/calf_big_styles/archive/refs/tags/1.0.0.tar.gz The only differences from the original styles are the font sizes. To run 'make' will show you how to install them. If Calf was installed into /usr, it should be as easy than su -c "PREFIX=/usr make install" The next time you run Calf, these styles will appear into the preferences widget. Enjoy, Dominique Calf Studio Gear: https://calf-studio-gear.org/ ___ Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
[LAD] Re: Status of Pipewire
Le Wed, 8 Feb 2023 13:03:37 +0100,
Lorenzo Sutton a écrit :
> Hi Fons,
>
> On 08/02/2023 12:09, Fons Adriaensen wrote:
> > Hello all,
Hello,
If I take a look at the gentoo pipewire ebuild, it is 2 jack related
USE flags: jack-client and jack-sdk
Their dependencies are as follow:
jack-client? ( >=media-sound/jack2-1.9.10:2[dbus] )
jack-sdk? ( !media-sound/jack-audio-connection-kit
!media-sound/jack2 )
Jack-client need jack2, but jack-sdk is blocking jack(2) because it
provide a replacement.
It is also a post install warning:
if ! use jack-sdk; then echo \
"JACK emulation is incomplete and not all programs will work.
PipeWire's alternative libraries have been installed to a
non-default location. To use them, put pw-jack before
every JACK application. When using pw-jack, do not run jackd/jackdbus.
However, a virtual/jack provider is still needed to compile the JACK
applications themselves."
And on the gentoo wiki https://wiki.gentoo.org/wiki/PipeWire
"Warning
As of mid 2022, PipeWire is still in active development. Some things
may still not be fully integrated, tested, or implemented, and there
may be large changes. It can work well for some, though the experience
is not guaranteed to be perfect, free of issues, or bugs."
Which mean that even with USE="jack-sdk", some use cases can get in
troubles.
> As said, this (at least logically), sounds really similar to the
> pulsaudio-jack sink concept... For instance what I now have in a
> script is something along the lines of:
>
> pactl load-module module-jack-sink
> pactl load-module module-jack-source
>
> and get pulseaudio as an in/out jack client.
Into my system, I don't use gnome or kde, so I never get the
point to use pulseaudio (it is not even installed), when we can do the
same using alsa and jack only. The default alsa card is defined
into /etc/modprobe.d/alsa.conf with a line
alias snd-card-0 snd-aloop
This also need a custom ~/.asoundrc file with something like
pcm.!default {
type plug
slave.pcm "jack";
}
ctl.!default {
type hw card 0
}
pcm.jack {
type jack
playback_ports {
0 system:playback_1
1 system:playback_2
}
capture_ports {
0 system:capture_1
1 system:capture_2
}
}
That way, the alsa only software will use by default the alsa default
card, and the clients of that aloop card will be rooted to jackd via
the jack ALSA plugin. They will even appear into the jack graph. jackd
is configured to use the real sound card.
That setting works fine for me with both qjackctl and cadence. It was
working with jackd and it works now with jack-dbus from years, that on
several computers.
Cheers,
Dominique
>
> >
> >
> > [1] which means I won't fall flat on my face in front of
> > a customer or a concert audience because of some software
> > hickup.
> >
> > Ciao,
> >
>
> Lorenzo
>
> [1] https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK
> ___
> Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
> To unsubscribe send an email to
> linux-audio-dev-le...@lists.linuxaudio.org
___
Linux-audio-dev mailing list -- linux-audio-dev@lists.linuxaudio.org
To unsubscribe send an email to linux-audio-dev-le...@lists.linuxaudio.org
Re: [LAD] A GUI request
Le Sun, 5 Jun 2022 21:49:13 +0100, Will Godfrey a écrit : > Therefore please consider either defaulting to a lighter layout, or > alternatively, at first time start give a choice using a system > alert/choice window. If you don't provide a lighter option, maybe > consider doing so. > Personally, I prefer dark themes but I understand very well Will's issue. I face a similar issue with small font sizes, they are just unreadable for me on a high definition screen. Accessibility is a very serious issue for a software to be usable by as many people than possible. As example, half of the African population cannot read text, which imply most software are just of no use for them. But, if a GUI include some text fields, please make them readable by anybody by providing some kind of font preferences. If that preference, or the theme preferences, are made by some config file or with environmental variables, please advertise about it into the documentation. Cheers, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Simple Pipewire test request
Le Fri, 9 Jul 2021 09:52:18 +0100, John Murphy a écrit : > On Fri, 9 Jul 2021 09:29:09 +0200 Dominique Michel wrote: > > On linux, the audio devices can be acceded by only 1 user at a time. > > Which imply, instead of being root for everything audio related, I > > would login as an user member of the audio group and, instead of > > using cron, make a custom user script. > > Thanks, but if Pipewire is going to prevent access to audio devices by > cronjobs, either accidentally or by design, then I'll be removing it. That issue have nothing to do with pipewire, but with how the kernel ALSA driver works. Which imply, instead of trying to workaround normal kernel operations and user/group permissions, you must work with them. It will be both much simpler and more reliable on the long run to use a joe user member of the audio group, and instead of messing with cron jobs which was never intended to be used to implement joe user tasks, just make a joe user (bash-python-...) script that will implement what you want to do. > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Simple Pipewire test request
Le Thu, 8 Jul 2021 19:12:29 -0700, Fernando Lopez-Lezcano a écrit : > >> It could also be that running things from cron does not establish a > >> "session" and then you do not have access permission to audio > >> devices and such (and dbus, as suggested elsewhere in the thread). > >> > > > > It's a long time since I've used root for anything, but I think it > > would still have the required permissions to do anything. I begin to > > wonder if this is by design, but I still don't know if it works for > > anyone else. On linux, the audio devices can be acceded by only 1 user at a time. Which imply, instead of being root for everything audio related, I would login as an user member of the audio group and, instead of using cron, make a custom user script. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Simple Pipewire test request
Le Wed, 7 Jul 2021 19:24:38 +0100, John Murphy a écrit : > On Wed, 7 Jul 2021 19:01:25 +0100 Keith Edmunds wrote: > > /tmp/cronjob.txt says error: pw_context_connect() failed: Host is down Maybe pipewire is not run by the same user than the cron job. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Is Piperware a successor to Jack/Pulseaudio?
Le Thu, 1 Jul 2021 18:57:59 -0400, bill-auger a écrit : > On Thu, 1 Jul 2021 07:01:31 +0100 Keith wrote: > > > The biggest issue with Pipewire IMHO is that it does not support > > > Ubuntu 18.04 LTS. > > > > I would suggest you have that round the wrong way: Ubuntu 18.04 > > doesn't support Pipewire. This is a Ubuntu problem, not a Pipewire > > one. If it matters to an 18.04 user, they do have the option of > > upgrading to 20.04. Distros do what they can. If your favourite software is not included, you can contribute to it by at least making a bug report asking for its addition. > the pipewire devs are the ones who had the option to decide > which distros it may be compatible with - obviously, ubuntu18 > was not one that "mattered" to them - but no project is obligated > to support any specific distro, so there is no fault there either Software developers make software, not distribution. They like when a distribution support their software, but they are not responsible for that. Also, if a given software builds and works on a given distribution, as example the distro(s) of the dev(s), it should work with all other distributions where the dependencies are satisfied. For pipewire, as systemd is an optional run time depend, it should builds and works on all distributions providing alsa, dbus, python and meson, which must be something like all not very old distributions. So again, if your favourite distro did not include pipewire, you can consider to contribute to it, or for an outdated distribution, to one of its external repository or overlay. Cheers, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] desktop icon, wm, desktop and audio software [kind of collective bug report]
Hi all, First, I will thank you all for all the great software you make. I am both a musician and the chief developer of fvwm-crystal http://fvwm-crystal.sourceforge.net/ I am very concerned with the look and feel of my desktop. Many audio software are providing both a desktop file and an icon file. The desktop file contain an Icon field of the form which is fine. That field is used by all Freedesktop compliant desktops in order to know the icon to display into the application menu. https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html Until then, fvwm-crystal and all other compliant desktops will find and display your software with its icon into their application menu. When running a software in X, most desktops can use 4 wm hints to know the names of the software window and of its icon, for things like the text to display into the title bar of the window or into the taskbar, or the icon to display into the pager or icon manager if any. Here, fvwm-crystal and other desktops are in trouble with a lot of audio software, that because these wm hints are not consistent with their icon name and the desktop fail to display their icon. These 4 files are "Name, "Icon Name", "Class" and "Resource". At least one of them must match the icon name provided by the application, otherwise many desktops will not know which icon to display outside of the application menu. As example, after starting radium, I get: Name: ** Radium - New song. ** Icon Name: ** Radium - New song. ** Class: radium_linux.bin Resource: radium_linux.bin when the icon provided by radium is radium.png. fvwm-crystal (and other wms/desktops as well) will not find the icon and display garbage instead in places like pager or icon manager. If at least one of these hints was just radium, it would just work fine. Name is the text displayed into the tittle bar and task bars. Icon Name should be appropriated but many software don't use it. Many software are using Class or Resource. Normally it doesn't matter which one a software is using, as long than at least one of them match . https://tronche.com/gui/x/icccm/sec-4.html I publish related style workarounds in fvwm-crystal for many audio software (just for that, it must be the desktop that have the best support of the linux audio software), but it is so much of them out there, and I just have a lot of other things to do than to test them all, or to report that issue to all of the ICCCM WM-HINTS non compliant ones. So please, consider to check your software for that issue and apply some fix when appropriated. A lot of desktop users will like such fixes. Best, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 9 soundcards ?
Le Mon, 11 Nov 2019 20:26:47 +0100, lacu...@gmx.net a écrit : > > Hello, > > > I'd like to run up to nine soundcards with Jack. > > Eight times Expert Sleepers ES-8 via USB > and one RME Madi HDSPe card on a PCIe slot. > > In Linux at 96 kilobauds. > > I read here > https://jackaudio.org/faq/multiple_devices.html > about clocking issues as each card is run by it's own clock. > > Will the asynchronously clocked streams be handled and merged by Jack > or is this an ongoing issue? It is an hardware issue. Each card have its own hardware clock, they are some kind of quartz oscillators often associated with PLL circuitry. They are implemented into the silicon of the cards and it is nothing JACK can do about this. The only solution would be to use a Master clock, which is to use the clock of one card as clock for all the cards. That can only be done at the hardware level. In your case, that imply to modify the hardware of the cards, which, with 8 USB of one brand and 1 PCI card of another brand would be rather complicated, if possible. Even if we consider only the 8 USB cards of the same brand, it is more than doubtful the clock of one of these cards would be powerful enough to be able to drive the 8 cards. Which imply this would not be a trivial modification. Dominique -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
Le Mon, 25 Jun 2018 18:31:12 -0400, Tim a écrit : > Hi list, some time ago a coder was asking about > making such an app. I think it's on github. > > Amazing what DSP audio and image coding can do these days. > Any thoughts on coding techniques? I've read a lot of papers! > Some say using FFTs + auto-correlation comparisons. > Some say non-negative matrix. > My head spins, but this team definitely deserves praise. > Can open source come up with something? To go fast and get a low enough latency, you can use can what time is between 2 consecutive peaks of the signal. Be aware than you would have to smooth the signal because when playing loud and the strings are touching the frets, the harmonic content become so weird you can get false maximums (as seen by a signal analysis of my electrical guitar with a memory oscilloscope), which will give you a much higher fundamental frequency than expected. Normal signal: * * * * * * * * * * ** ** * ** * * * * * *=*=*=* * * * * ** ** * * * * * * * * * * Fretted signal: * * * * * ** * * ** * * * * * * * * * * * * ** * * * * * *=*=*=* * * * * ** ** * * * * * * * * * * These double peaks can be very huge as an electrical guitar have a huge dynamic during the attack of the notes. Doing a repetitive arithmetic average calculation when the sampling are coming in must be enough to smooth them in real time, and to get ride of other high order harmonics at the same time. The latency will be dependant of the fundamental frequency, something like one period + trigger delay. Cheers, Dom > > Cheers, Tim. > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev -- If you have a problem and you are not doing anything to fix it, you are at the heart of the problem. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] FVWM-Crystal-3.3.2 is out
This is an exceptional announcement. You may ask why announce a FVWM-Crystal release on the LAA, fvwm-crystal being a desktop. That's simple, fvwm-crystal was improved in 3.3.0 with a key modifier editor which let you change its key modifiers. This will affect only the extensive set of fvwm-crystal own key-bindings, and the key bindings of other applications will remain fully unaffected. That's a very easy and fast way to have the extensive key-bindings set of applications like ardour or emacs to not collide with the desktop. During the last 2 years, a lot of bug fixes was done, the existing features was improved and unified between the recipes, and new features was added. The list of changes is so huge that it is better to try it for yourself, if you don't already have done it. During the last few months, a particular effort was made to fix some nasty bashisms. That should make fvwm-crystal to work much better with distributions using dash as default shell, and fix one hopefully unnoticed security issue. A short and very partial story of the last releases: 3.3.2 bring 2 new recipes with ACPI support (battery, cpu speed and temperature). 3.3.1 bring a new and complete Dutch translation and a Preference Editor for the preferences that don't have menu options. It bring too a pot file for easy translations in new languages. 3.2.6 see an updated Russian translation and x-terminal-emulator support (Debian). 3.2.4 add mount/umount/pmount/pmount-gui support with the built-in desktop icons. 3.2.1 finally succeed to remove the restart with all preference changes but one. 3.2 see a complete rewrite of the Thunar desktop icons manager. Not only the buttons was redone from the scratch into a single button, which fix the flickering, but also a new implementation of the associated actions was done. Now it's possible to associate any file manager you can think about with these icons, 2 are supported at the same time, as well than custom commands. ... For a complete list, see the ChangeLog file. Download: https://sourceforge.net/projects/fvwm-crystal/files/?source=navbar Website: http://fvwm-crystal.sourceforge.net/ Project site: https://sourceforge.net/projects/fvwm-crystal/?source=navbar Enjoy, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Releasing source code is not enough, I think...
Le Wed, 22 Jan 2014 16:49:06 -0500, Fred Gleason fr...@paravelsystems.com a écrit : On Jan 21, 2014, at 13:10 30, Filipe Coelho fal...@gmail.com wrote: That's why I'm planning to do a small, *developer*-oriented tutorial on how to get the most generic binaries possible. Something that can work as widely as possible. Unfortunately, the ambit of a downstream maintainer is a lot larger than just producing a runnable binary. Just some of the high points: 1) Do the menu item(s) integrate themselves into the overall tree in a way that makes sense given the distro’s overall menu arrangement? It was the main reason why I begun to use FVWM-Crystal it was a few years ago. It doesn't care about the files into /etc/xdg which, in most cases if not all cases, have only a limited support for the freedesktop additional categories. Instead, it only look for the categories into the desktop files provided by the applications in /usr/share/applications. The result is a full support for the additional categories and a menu that will look the same with any distribution, that out of the box. Also, it contain a few non in the norm categories for the Audio category, like Sequencer or Notation, and it have a main Multimedia category with 3 categories for Audio, AudioVideo and Video. The last version of yesterday contain a preference editor for its key modifiers. This is an easy way for fvwm-crystal's bindings to not collide with software like ardour or emacs. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Releasing source code is not enough, I think...
Le Tue, 21 Jan 2014 17:11:10 +, Filipe Coelho fal...@gmail.com a écrit : On 01/21/2014 05:00 PM, Fons Adriaensen wrote: On Tue, Jan 21, 2014 at 03:34:05PM +, Filipe Coelho wrote: I seriously don't wish any new user to have to put up with this. It might be easy for us that are now used to this sort of things, but not for them. Then they should wait until their distro or someone else provides a package. Or pay someone to do the work for them, just as they have to for commercial software, or for the mechanic you mention. Or use a distro that usually provides a shorter release cycle, e.g. Arch (which is not for noobs). What about all the freeware software I see in Windows/OSX? It's the only way they (software devs) have to get some attention to it. afaik no one is paying them. I don't think a sane person is willing to wait ~6 months and do a reinstall just for a bug-fix release (in case of Ubuntu). Unless that toolchain can magically create packages for all major distros (and I'm pretty sure it can't do that), what's the point ? It won't create packages, it will create binaries - which is what users are looking for. And how are these installed ? Bypassing the distro package management is a sure recipe for misery. Maybe not immediately, with a bit of luck the binary you just copied to /usr/bin may work. But sooner or later your users will get some serious trouble, because you're messing up their systems. If that's what you want, go on... It is why at the first place, I shifted to gentoo. When I install a software myself, I first compile it and install it in /usr/local, but this is just to see how the installation process work and its dependencies. After that I remove it and do an ebuild. The result will be the same, but with the same optimisations than the rest of the system, and all the files, their dependencies and reverse dependencies will be managed by portage. If the software is audio related, I put it into the pro-audio overlay. Otherwise, I do a bug report with the ebuild on the gentoo bugzilla most of the times. Sometime I do both. I don't see how this is worse than having the users installing files to /usr/local. I actually think it's much better, since it won't require root to install. Just run the binary. ~/bin also exists, although not all distros use it. Sure, it will be better than on windows where every thing is installed at the same place, that with no management of the libraries, but idiotic questions that even a programmer cannot answer. The users will be fine in most cases in the short run, but in the long run, they will get in troubles. This is the same problem with all the binary based distributions and their additional repositories. More repositories you add, more troubles you will get with broken deps when updating the system. And with files, and maybe even libraries, installed into /usr/local, this is even worst, because the system update will be fine, but the result will soon or later be a broken system. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK, cgroups and systemd
Le Sun, 12 Jan 2014 16:46:56 -1000, Joel Roth jo...@pobox.com a écrit : Dominique Michel wrote: Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I run sid, however continue to use sysvinit. That's not the matter. When I installed it, systemd was installed, and it doesn't work with a non automatic cgroups configuration. For what I know, it will be the same problem with any installation using systemd, that because the cgroup feature of systemd is designed to only work with the automatic kernel cgroups stuff, or to reproduce it. In the case of a rt setup as the one on the jack wiki, this just fail because systemd is designed to pollute the only cpu group we are using, which is a real time group, with applications that have nothing to do in it, and this is so bad it can result into a complete system freeze. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK, cgroups and systemd
Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I found the reason here: http://article.gmane.org/gmane.linux.kernel/1063354 Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). Another completely idiotic stuff of this guy. The point of the cgroups is it is possible to setup them for whatever use will be made with a computer, and this guy think he have the insane and pretentious capability to decide for every single user of the use they will made with their computers, and he is suggesting users doing something else are abnormal. He must be stopped! Regards, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Le Mon, 13 Jan 2014 00:22:40 +1100 (EST), Patrick Shirkey pshir...@boosthardware.com a écrit : On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote: Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I found the reason here: http://article.gmane.org/gmane.linux.kernel/1063354 Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). Another completely idiotic stuff of this guy. The point of the cgroups is it is possible to setup them for whatever use will be made with a computer, and this guy think he have the insane and pretentious capability to decide for every single user of the use they will made with their computers, and he is suggesting users doing something else are abnormal. He must be stopped! That patch is over three years old. It seems like you have found a loophole in the logic that was used to justify it. Granted, it's annoying but it just means we have to find a better solution. Similar to Fon's main objection to jack-session being *not flexible enough*. We all knew it would cause problems for specific use cases but we still haven't found a perfect solution to enable the flexibility that Fons identified while also allowing people to get on with the task at hand. Hence we have the less flexible but still useful for most use cases version of jack session. With the cgroups, that flexibility exist. One of the main point of the cgroups is to be flexible enough to be setup for any possible use case. But with a systemd system, that flexibility doesn't exist any more, because the only possible normal use case permitted by systemd is to run a GUI (as stated by the normal one in charge of this mess). It is more than 1 year I use the cgroups within an openrc system, and you can do whatever you want with the cgroups. The same apply for sysv init system. What made me mad in that story, is not because it is a bug into systemd which made a kernel function to misbehave, I know very well that the only one that doesn't make bugs is the one that doesn't make code, but this is the complete lack of consideration for other needs than what he consider to be the needs of a normal desktop user. Which strongly suggest users with other needs are abnormal users. Which in turn imply that person is a racist when he suggest I am abnormal. And I am not the only one, systemd will break any cgroup configuration for any other use case than to run a GUI. Dominique -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Le Mon, 13 Jan 2014 02:39:08 +1100 (EST), Patrick Shirkey pshir...@boosthardware.com a écrit : On Mon, January 13, 2014 2:28 am, Dominique Michel wrote: Le Mon, 13 Jan 2014 00:22:40 +1100 (EST), Patrick Shirkey pshir...@boosthardware.com a écrit : On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote: Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I found the reason here: http://article.gmane.org/gmane.linux.kernel/1063354 Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). Another completely idiotic stuff of this guy. The point of the cgroups is it is possible to setup them for whatever use will be made with a computer, and this guy think he have the insane and pretentious capability to decide for every single user of the use they will made with their computers, and he is suggesting users doing something else are abnormal. He must be stopped! That patch is over three years old. It seems like you have found a loophole in the logic that was used to justify it. Granted, it's annoying but it just means we have to find a better solution. Similar to Fon's main objection to jack-session being *not flexible enough*. We all knew it would cause problems for specific use cases but we still haven't found a perfect solution to enable the flexibility that Fons identified while also allowing people to get on with the task at hand. Hence we have the less flexible but still useful for most use cases version of jack session. With the cgroups, that flexibility exist. One of the main point of the cgroups is to be flexible enough to be setup for any possible use case. But with a systemd system, that flexibility doesn't exist any more, because the only possible normal use case permitted by systemd is to run a GUI (as stated by the normal one in charge of this mess). It is more than 1 year I use the cgroups within an openrc system, and you can do whatever you want with the cgroups. The same apply for sysv init system. What made me mad in that story, is not because it is a bug into systemd which made a kernel function to misbehave, I know very well that the only one that doesn't make bugs is the one that doesn't make code, but this is the complete lack of consideration for other needs than what he consider to be the needs of a normal desktop user. Which strongly suggest users with other needs are abnormal users. Which in turn imply that person is a racist when he suggest I am abnormal. And I am not the only one, systemd will break any cgroup configuration for any other use case than to run a GUI. Well we also see similar issues with PA and JACK. The reasoning appears to be that the different camps are not really interested or motivated to scratch each others itches and no one is being paid to do the dirty work to make sure the corner cases are being polished. I am working on getting some official funding for the latter so this issue interests me from that perspective. I can only hope you will succeed with that. It seems the days are over when people had the time or motivation to fix the tricky and annoying integration issues under there own steam. I can understand this when some developers seam use their time to break the kernel and other important functions. We get udev breakage of firmware loading with some modules, the *kit story which will hopefully end with its disappearance, and now systemd which have a catastrophic implementation. And that's only the ones I am aware of. Dominique -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
Le Sun, 12 Jan 2014 22:37:34 +0100, Philipp Überbacher mu...@tuxfamily.org a écrit : On Sun, 12 Jan 2014 22:20:06 +0100 (CET) k...@aspodata.se wrote: Dominique: Le Mon, 13 Jan 2014 02:39:08 +1100 (EST), Patrick Shirkey pshir...@boosthardware.com a écrit : On Mon, January 13, 2014 2:28 am, Dominique Michel wrote: Le Mon, 13 Jan 2014 00:22:40 +1100 (EST), Patrick Shirkey pshir...@boosthardware.com a écrit : On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote: Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. ... I can understand this when some developers seam use their time to break the kernel and other important functions. We get udev breakage of firmware loading with some modules, the *kit story which will hopefully end with its disappearance, and now systemd which have a catastrophic implementation. And that's only the ones I am aware of. The sad part is that distributions and some programs have stopped to respect the local administrator, by implementing more and more policy. Regards, /Karl Hammar The usual answer that I get for criticism like that is: Well, you can change it.. The problem is that the effort to do so is often too large to make this a practical option. I'm not sure how it is in this case though, is it possible to change the behavior of systemd without code change? No, in the same link I put in the first mail, Lennart say: In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). On a system that runs systemd for both managing users and sessions this means you are already half-way at what you want. He concede this systemd patch is onhly half of what the kernel can do when correctly used. And he conclude: Well, if I make behaviour like this default in systemd, then this means there won't be user setup for this. Because the distros shipping systemd will get this as default behaviour. His is talking about implementing in systemd something similar to the automatic cgroups stuff if the kernel. For what I know, this is the only thing that is implemented into systemd for the cgroups, and it is only cosmetic possibilities to configure them with systemd. This is way I also think we are not the only ones concerned, but any body using something else than the automatic kernel cgroups stuff is concerned. I do try to stay away from things that I don't need (polkit, systemd, PA, *kit, ...) but it's not always possible. I can hardly maintain an init system in parallel to the one my distribution uses. It is why I replaced debian by gentoo. It it even an udev fork, eudev, which is udev without the crap. Some of my USE flags are -policykit -consolekit -udisks -udisks2 -pulseaudio, and I masked udev and installed eudev instead. Anyway, I launched another discussion on that topic on systemd email list: http://lists.freedesktop.org/mailman/listinfo/systemd-devel http://lists.freedesktop.org/archives/systemd-devel/2014-January/016110.html As I understand it, the problem is related with a basic miss-conception of what an user is doing with its computer. For peoples like Lennart (it is other like him at freedesktop and in some distributions, and maybe also elsewhere, the users are running a modern GUI. For them, it is 3 of them, kde, gnome and xfce, and all other use cases are not relevant to them. In other words, for them, an user doesn't work with its computer but he is running a modern GUI. Beside to not use systemd, the only solution to solve that mess is to rewrite the cgroups API of systemd, so that it will support all the cgroups features, and not only a subset, and so that the users can configure it. Maybe he will put a java script interpreter into systemd -:) Dominique Regards, Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Tue, 07 Jan 2014 17:03:28 +0100, Ralf Mardorf ralf.mard...@alice-dsl.net a écrit : On Tue, 2014-01-07 at 00:22 +, Fons Adriaensen wrote: On Tue, Jan 07, 2014 at 12:32:02AM +0100, Dominique Michel wrote: ... mainstream physics doesn't validate Evans' theory (as it didn't validated Galileo's theory at his time) That is one of the most intellectually dishonest analogies I've seen so far. Galileo's theories were not rejected by fellow scientist - those who repeated his observations tended to agree. He was silenced because he undermined the teachings of the Catholic Church. No such thing happened to Evans. His theories were discredited because his argumentation contained mathematical errors. These have been published and can be verified by everyone who cares. Since it seems to continue on the list. I agree with Fons statement, but IMO it's likely that in the future physics will change a lot assumed humans will survive another 2000 years or longer. If we were living into an ideal society, I would agree 100% with Fons statement. But that's not the case. It is why I pose the doubt and prefer to say I don't know. That's for the theoretical case. Now, for the practical case, I think Fons is right, because from the time Bearden say he have a working device, nobody have seen it. Dominique Forwarded Message From: Ralf Mardorf To: Dominique Michel Subject: [off-list][LAD] Audio Levitation Date: Tue, 07 Jan 2014 16:59:36 +0100 Mailer: Evolution 3.10.3 On Tue, 2014-01-07 at 00:32 +0100, Dominique Michel wrote: I just say it is other theories today than the one we learn at school That's true and it even might be that the law of conservation of energy someday will be outdated. Nowadays it's just that most, if not all super-ideas are simply nonsense. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Mon, 06 Jan 2014 00:38:10 +0100, Ralf Mardorf ralf.mard...@alice-dsl.net a écrit : On Sun, 2014-01-05 at 22:31 +, Fons Adriaensen wrote: On Sun, Jan 05, 2014 at 08:41:55PM +0100, Dominique Michel wrote: Allow things like the Bohren experiment which give us up to 18 times more energy at the output than the input energy. [snip] The effect is the same as putting a large lens in front of a small target. I get the impression that some on this list doubt the law of conservation of energy. I didn't follow the whole thread, perhaps I missed something. No I don't say that, I just say it is other theories today than the one we learn at school, theories where the topological space under consideration is described by an O(3) group rather than by an U(1) group, as described by Evans. One of the main Evans' claim is that more things are possible into an O(3) group of reference. I also know that mainstream physics doesn't validate Evans' theory (as it didn't validated Galileo's theory at his time), that mainstream physics and Evans as well, doesn't know every thing, and that all papers exists and can be read by every one to draw its own conclusion. If Evans is right, and I don't know the answer (some papers disagree with him, other agrees, and I am not a specialist in physics but in electronics), his theory will also have great theological consequences. Among other things, he unify the 4 fundamental forces of physics into one. That imply if one force is at the origin of every thing, and can be expressed by mathematics, it cannot be personified and called God at the same time. This can be one more good reason why mainstream physics will suppress him. In our society, the ones that fund the research are often the same than the ones that fund the politicians, and I remember it was about 20 years ago, the scientists at the CERN which was working at unifying the fundamental forces was very choked when, without any warning, their research was cancelled. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Mon, 6 Jan 2014 20:11:13 -0500,
Paul Davis p...@linuxaudiosystems.com a écrit :
On Mon, Jan 6, 2014 at 7:22 PM, Fons Adriaensen f...@linuxaudio.org
wrote:
On Tue, Jan 07, 2014 at 12:32:02AM +0100, Dominique Michel wrote:
... mainstream physics doesn't validate Evans' theory (as it
didn't validated Galileo's theory at his time)
That is one of the most intellectually dishonest analogies I've
seen so far. Galileo's theories were not rejected by fellow
scientist - those who repeated his observations tended to agree.
He was silenced because he undermined the teachings of the
Catholic Church.
No such thing happened to Evans. His theories were discredited
because his argumentation contained mathematical errors. These
have been published and can be verified by everyone who cares.
specifically:
http://arxiv.org/abs/physics/0607186
Correcting a former proof of M.W. Evans it is shown that his O(3)
hypothesis is not Lorentz invariant and hence no law of Physics.
http://adsabs.harvard.edu/abs/2008AcPPB..39...51B
We comment on the recent article of M.W. Evans, Spin Connection
Resonance in Gravitational General Relativity, Acta Phys. Pol. B
{38}, 2211 (2007). We point out that the equations underlying Evans'
theory are highly problematic. Moreover, we demonstrate that the
so-called ``spin connection resonance'', predicted by Evans, cannot
be derived from the equation he used. We provide an exact solution of
Evans' corresponding equation and show that it has definitely no
resonance solutions.
http://arxiv.org/abs/math-ph/0411085
I know these papers, they are just a part of the story. Evans and other
scientists refuted them all. We can find them in the rebuttals section
of http://www.atomicprecision.com/Community/content.html
Compare and contrast for interesting sociological effect, if you
will, to the treatment received by Galileo.
Evans was not killed, I know that. On the other hand, the UN said it
is more than enough food on earth for every one, and that 35 millions of
peoples are staving to death each single year. It's a sociological
effect which have one single reason, these peoples are to poor to buy
the food that exist for them on the markets. It is called capitalism. I
don't think either that communism is better. They are just 2 sides of
the same reality. But from a few decades ago, capitalism is the only one
left, so we cannot blame others any longer for the total failure of
capitalism to archive peace and prosperity for every one on earth.
The root of the problem is respect, and as we don't respect Nature, we
don't respect each others. Capitalism exploit Nature for profit,
Communism exploit Nature for the sole satisfaction of Humanity. In both
cases this is the same egoistic bullshit where the satisfaction of
Nature is just not taken in account. Communism is right on one thing:
the economy must be just a tool, and for that, it have to be
subordinated to the goal. But as our relationship with Nature is what
affects the whole ontology of our society (among others, see Philippe
Descola on this), economy must be subordinated not only to the
satisfaction of every body's needs, but also to the satisfaction of the
needs of Nature. In other words, a society based on the exploitation of
Nature can and will generate a society of exploitation of each others.
In our case, that exploitation is industrialised at all levels, and NSA
is just a step further to total exploitation of humanity. So Houston, we
have a big problem here. And to know if Evans is right or wrong is
totally secondary.
Dominique
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Sun, 05 Jan 2014 13:50:52 +0100, Ralf Mardorf ralf.mard...@alice-dsl.net a écrit : On Sun, 2014-01-05 at 00:29 +0100, Dominique Michel wrote: And classical physics is even worst. In Einstein formula e=mc^2, the only term for which we have a definition is c... For e, it is no definition, only equations which are not definitions https://upload.wikimedia.org/wikipedia/commons/thumb/c/c9/E%3Dmc%C2% B2-explication.svg/220px-E%3Dmc%C2%B2-explication.svg.png The Definition for E is m*c². By your explanation we would als have no definition for c, since c also is an equation, c is m/s (another m ;). The only differences are that some values are constants and others are variables. That's an equation. A definition is with ==, not =. The definition of energy is the capacity to do some work, and as both work and energy share the same unit, the Joule, we get that work is equivalent to energy, as we learn it at school. Maxwell's theory as we learn it at school (which is a truncation of its original 1865 theory made by Heaveside, Herz and Gibbs) doesn't allow things like the Bohren experiment which give us up to 18 times more energy at the output than the input energy. But the fact remain that the Bohren experiment can be reproduced, and have been reproduced. Hopefully, it is other theories slowly emerging like the electrodynamics (O3), Sachs work and the unified field theory of Evans, that mix Maxwell's original theory (which is relativistic) with general relativity, quantum physics, and with new advances like Whitaker EM decomposition and broken symmetry, to get a new theory where coefficient of efficiency 1 are achievable. The main issue here is money, the one that make big money with the energy are the ones that found most research in that field. More, Maxwell was assuming a material ether, therefore the assumption of EM fields in vacuum, but EM fields just cannot exist without particles. They are not a cause but an effect of the particles: In my considered opinion I think that a photon is a manifestation of spacetime curvature, the result of quantization of the electromagnetic field tensor in antisymmetrized general relativity. Evans, the author of The Enigmatic Photon. A photon is a magnetic dipole. It is an elementary magnet. Evans' discovery of the photon's longitudinal magnetic field in 1992 is as significant, at the quantum level, as Einstein's discovery of relativity at the universal level. It helps to give a physical interpretation to string theory, wave mechanics, two-slit interference and the Faraday effect. A string is a harmonically moving photon that vibrates, oscillates, spins and twists. K. L. Rajpal Among all the vulgarisation that is in Bearden's web site, see http://www.cheniere.org/references/index.htm for references. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Sat, 4 Jan 2014 13:39:05 +, Fons Adriaensen f...@linuxaudio.org a écrit : On Sat, Jan 04, 2014 at 09:24:54PM +1100, Patrick Shirkey wrote: Does cavitation have a role to play? No idea. If it does that could be rather destructive on some materials. Acoustic, inclusive acoustic levitation, already have uses. The army use it (at least from the Vietnam war), the chemical and drug industry use it or have plans to use it, etc. http://www.youtube.com/watch?v=1jvcgz-BiHs Dominique What is clear is that acoustic radiation pressure plays a role. And that's a subject that has caused a lot of confusion and false results throughout the history of acoustics as a science. Some big names (including Rayleigh) have burnt their fingers on it, so it's not and easy matter. To prime the confusion, there are at least two formulations of acoustic radiation pressure: one from Rayleigh (which depends on non-linearity) and one due to Langevin (which does not depend on it). Ciao, ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Sat, 4 Jan 2014 13:39:05 +, Fons Adriaensen f...@linuxaudio.org a écrit : On Sat, Jan 04, 2014 at 09:24:54PM +1100, Patrick Shirkey wrote: Does cavitation have a role to play? No idea. If it does that could be rather destructive on some materials. What is clear is that acoustic radiation pressure plays a role. And that's a subject that has caused a lot of confusion and false results throughout the history of acoustics as a science. Some big names (including Rayleigh) have burnt their fingers on it, so it's not and easy matter. To prime the confusion, there are at least two formulations of acoustic radiation pressure: one from Rayleigh (which depends on non-linearity) and one due to Langevin (which does not depend on it). According to that presentation http://www.dalembert.upmc.fr/Oleron2010/docs/Presentations/Oleron-Barriere.pdf it look like Langevin (which is the same than Rayleigh first formula in 1902) apply well when we are long enough from the source, and when we are in its vicinity, Rayleigh (1905) must be applied. Dominique Ciao, ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
Le Sat, 4 Jan 2014 20:19:27 +, Fons Adriaensen f...@linuxaudio.org a écrit : On Sat, Jan 04, 2014 at 06:16:31PM +0100, Dominique Michel wrote: According to that presentation http://www.dalembert.upmc.fr/Oleron2010/docs/Presentations/Oleron-Barriere.pdf it look like Langevin (which is the same than Rayleigh first formula in 1902) apply well when we are long enough from the source, and when we are in its vicinity, Rayleigh (1905) must be applied. Interesting, thanks for the pointer. And it closes the circle... The first slide is a quote from one of Beyer's papers: It might be said that radiation pressure is a phenomenon that the observer thinks he understands — for short intervals, and only every now and then” I remember reading the paper that comes from a very long time ago, and that was what inspired my remark about radiation pressure being one of the more elusive topics in acoustics ! And classical physics is even worst. In Einstein formula e=mc^2, the only term for which we have a definition is c... For e, it is no definition, only equations which are not definitions, and this is the same issue with m=e/c^2, which is maybe the less obvious equation of all equations. Ciao, Dominique Ciao, ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] io GNU/Linux LiveDVD/USB ... 64-bit iso up :)
Le Tue, 31 Dec 2013 17:04:54 +0100, Brendan Jones brendan.jones...@gmail.com a écrit : On 12/31/2013 04:56 PM, Ralf Mardorf wrote: On Tue, 31 Dec 2013 16:47:16 +0100, MK aka El Doctor el.doc...@laposte.net wrote: http://manu.kebab.free.fr/io/releases/io-live-hybrid-3.12.6-amd64--2013.12.29-07.11.packages.html Is there a good reason why Debian based distros exclude linuxsampler? Same reason why we don't include it in Fedora Jam. It's a non-free license. __ I don't see where the problem is with Debian. I made a Debian install for testing in virtualbox the other day, and the installation program asked me if I want to include the non-free software into the installation. So, if the user is able to say yes to that question, the real reason is something else. In gentoo, we have another politic with the licences. The free licence are accepted by portage by default, and for the other licences, the user must accept them on a per package basis. For linuxsampler, both the portage versions and the pro-audio overlay live version are considered as GPL2, as stated into the source code. gsampler, qsampler and jsampler are also provided. The jsampler ebuilds let the user to choose between the classic and fantasia installation. Dominique _ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] io GNU/Linux LiveDVD/USB ... 64-bit iso up :)
Le Tue, 31 Dec 2013 12:08:23 -0500, Paul Davis p...@linuxaudiosystems.com a écrit : On Tue, Dec 31, 2013 at 12:26 PM, Dominique Michel dominique.mic...@vtxnet.ch wrote: In gentoo, we have another politic with the licences. The free licence are accepted by portage by default, and for the other licences, the user must accept them on a per package basis. For linuxsampler, both the portage versions and the pro-audio overlay live version are considered as GPL2, as stated into the source code. It isn't clear that linuxsampler's license is legal. They use the GPL2 and then add restrictions, which is prohibited by the GPL. It may or may not affect the license, but either way it is a wierd situation. Sorry Paul for the double posting, I just hit Answer and it din't make it to the list. Is it not the point of the GPL3 to be a free license that allow to make anything with the work done with the software, but to restrict commercial distribution of the code or the software? Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Community Interaction and Working Together
Le Fri, 20 Sep 2013 14:54:46 +0200, michel dominique dominique.mic...@vtxnet.ch a écrit : On ven. 20/09/13 13:11 , Harry van Haaren harryhaa...@gmail.com wrote: Hello all Users Devs of linux-audio-land, Moving forward from the topic on Aeolus and forking projects, perhaps it is wise to look at how the community as a whole can grow from this situation: 1) It seems the frustration of forks is mainly due to lack of communication. 2) Had appropriate communication been in place, patches could have been merged. 3) If 1) and 2), then the community flourishes as a whole. In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its relevant here): That imply we must communicate more with each other I think this is a big problem, and not only related to Fons work, or the LAD, but to the whole community. One think I have done is to add in the About box a few buttons to launch things like the mail list subscription page, mailto and irc. The function look for $BROWSER, if it doesn't exist, the user get the opportunity to set it, and the browser will do the rest. It is too early now for me to know if it make a big difference. This will not replace an email list, but can be a good complement, and make life easier for someone that want to get in touch with the development, or have an issue, a comment or whatever to ask or report. A little follow up. A few months later, I can see this added feature didn't changed much, at least for what I can see. I get a few direct mails, but not many. And no spam -:) In the meantime, I started some threads in both the forum of my distribution, gentoo, and on a French forum, LinuxMAO. I get very interesting returns on these treads, and very different as well. Gentoo's users are generally more skilled than LinuxMAO's users. So, in one thread I get interesting returns mostly from a developer point of view, in the other, mostly from an user point of view. Both are interesting and mostly positive, even if sometime it can not be easy to figure out what is going on for an user, this due to a lack of specific information. In consequence, these forum threads are definitely a good complement for the mailing list to me. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Community Interaction and Working Together
Le Fri, 20 Sep 2013 14:54:46 +0200, michel dominique dominique.mic...@vtxnet.ch a écrit : On ven. 20/09/13 13:11 , Harry van Haaren harryhaa...@gmail.com wrote: Hello all Users Devs of linux-audio-land, Moving forward from the topic on Aeolus and forking projects, perhaps it is wise to look at how the community as a whole can grow from this situation: 1) It seems the frustration of forks is mainly due to lack of communication. 2) Had appropriate communication been in place, patches could have been merged. 3) If 1) and 2), then the community flourishes as a whole. In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its relevant here): That imply we must communicate more with each other I think this is a big problem, and not only related to Fons work, or the LAD, but to the whole community. One think I have done is to add in the About box a few buttons to launch things like the mail list subscription page, mailto and irc. The function look for $BROWSER, if it doesn't exist, the user get the opportunity to set it, and the browser will do the rest. It is too early now for me to know if it make a big difference. This will not replace an email list, but can be a good complement, and make life easier for someone that want to get in touch with the development, or have an issue, a comment or whatever to ask or report. A little follow up. A few months later, I can see this added feature didn't changed much, at least for what I can see. I get a few direct mails, but not many. And no spam -:) In the meantime, I started some threads in both the forum of my distribution, gentoo, and on a French forum, LinuxMAO. I get very interesting returns on these treads, and very different as well. Gentoo's users are generally more skilled than LinuxMAO's users. So, in one thread I get interesting returns mostly from a developer point of view, in the other, mostly from an user point of view. Both are interesting and mostly positive, even if sometime it can not be easy to figure out what is going on for an user, this due to a lack of specific information. In consequence, these forum threads are definitely a good complement for the mailing list to me. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Screencasting with JACK [SOLVED!]
Le Thu, 8 Aug 2013 18:54:29 -0700,
J. Liles malnour...@gmail.com a écrit :
As some of you may recall, every time I've posted a demo video to
LAD, I've had to include a disclaimer excusing the poor quality due
to a lack of functional screencasting tools.
Well, it took a couple of weeks of hair pulling and many, many hours
of testing, but I finally arrived at a solution.
Anyone who wants to create a screencast and record audio via JACK *in
perfect sync* must do the following:
Get ffmpeg. Apply this patch to it:
https://github.com/original-male/FFmpeg/commit/d02509d04d396a98646ca81e9ba327a501486130.patch
Build it with vorbis and h264 support.
Then, start your favorite desktop environment. I use Xephyr for this.
Have jack running (at -r 48000)
Then run the following command:
ffmpeg -fflags +genpts+igndts -f x11grab -vsync 0 -r 30 -s 1920x1080
-i :${DISPLAY}.+0,0 -vcodec h264 -f jack -ac 2 -r:a 48000 -i
screencast -acodec pcm_s16le -r:v 30 -vsync 2 -async 1 -map 0:0,1,0
-map 1:0 -preset ultrafast -qp 0 $FILE
Where DISPLAY is the number of your X11 display and FILE is the
filename for the screencast. I use a .mkv extension for the matroska
container.
Remember to connect the streams you want recorded to the 'screencast'
JACK inputs!
With this setup I'm able to record a full 30 FPS @ 1080P with audio in
perfect sync. Please share your results too. With some more evidence I
might have a good case to get ffmpeg to accept my patch.
It work fine, thank you.
My screen is 1280 by 1024 on a phenom amd64 system.
When searching for an explanation for the -i display parameter, I find
screecastor. You may be interested by it:
http://www.hecticgeek.com/2012/12/screencastor-screen-recorder-ubuntu/
http://hizo.fr/linux/screencastor/
To make it work with jack, you can edit directly the ffmpeg command, or
change 2 of screencaptor's files:
In go_screencastor.sh:
–combobox=’@@_audio_provenance@@col
pulse
/dev/dsp1
ffmpegjack
hw:0,0
hw:1,0′ \
and
–combobox=’@@_audio_serveur@@col
alsa
jack
oss’ \
In screencastor.sh:
case « ${G2S_audio_provenance} » in
0) G2S_audio_provenance=pulse ;;
1) G2S_audio_provenance=/dev/dsp1 ;;
2) G2S_audio_provenance=ffmpegjack ;;
3) G2S_audio_provenance=hw:0,0 ;;
4) G2S_audio_provenance=hw:1,0 ;;
esac
case « ${G2S_audio_serveur} » in
0) G2S_audio_serveur=alsa ;;
1) G2S_audio_serveur=jack ;;
2) G2S_audio_serveur=oss ;;
esac
Dominique
Enjoy!
--
We have the heroes we deserve.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] zita-ajbridge and aloop
Le Thu, 11 Jul 2013 14:52:28 -1000, Joel Roth jo...@pobox.com a écrit : Dominique Michel wrote: Le Thu, 11 Jul 2013 15:59:09 +0200, IOhannes m zmoelnig zmoel...@iem.at a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, (apologies if this is the wrong mailing list, but i'm currently only subscribed to LAD and not LAU. anyhow:) i'm having serious troubles using zita-ajbridge with alsa loopback devices. my basic requirement is, to allow *any* ALSA-only application to be jackified. i'm on debian, and my current tests are done on i386 resp. x86_64, but my target platform is armel (wandboard solo, powered by a single-core ARM cortex-A9) the basic problem i'm facing is, that i don't get much output. occasionally i do get output (e.g. with mplayer) so here's what i did: # modprobe snd-aloop (with all the default parameters) which gives me: $ cat /proc/asound/cards 0 [Generic]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xf0244000 irq 43 1 [SB ]: HDA-Intel - HDA ATI SB HDA ATI SB at 0xf024 irq 16 2 [Loopback ]: Loopback - Loopback Loopback 1 You can setup /etc/modules.d/alsa.conf, or whatever file used by Debian to configure the ALSA driver, to define the Loopback as card 0. That way, all the ALSA program will access the loopback by default. Of course, jackd must be running all the time for that to be useful. Will pulseaudio accept the loopback device defined as card 0? It would be nice to have a bone to throw to pulseaudio. More and more of my distribution's packages seem to depend on it, including that for a widely used video-conferencing client. I don't know. pulseaudio is not installed into my system. I don't want polkit, so I removed the whole of gnome :P) But I think it should work, pulseaudio have both a jack sink that can output directly to jack, and an alsa sink that can output to alsa. Joel Dominique -- We have the heroes we deserve. -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] zita-ajbridge and aloop
Le Thu, 11 Jul 2013 15:59:09 +0200, IOhannes m zmoelnig zmoel...@iem.at a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, (apologies if this is the wrong mailing list, but i'm currently only subscribed to LAD and not LAU. anyhow:) i'm having serious troubles using zita-ajbridge with alsa loopback devices. my basic requirement is, to allow *any* ALSA-only application to be jackified. i'm on debian, and my current tests are done on i386 resp. x86_64, but my target platform is armel (wandboard solo, powered by a single-core ARM cortex-A9) the basic problem i'm facing is, that i don't get much output. occasionally i do get output (e.g. with mplayer) so here's what i did: # modprobe snd-aloop (with all the default parameters) which gives me: $ cat /proc/asound/cards 0 [Generic]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xf0244000 irq 43 1 [SB ]: HDA-Intel - HDA ATI SB HDA ATI SB at 0xf024 irq 16 2 [Loopback ]: Loopback - Loopback Loopback 1 You can setup /etc/modules.d/alsa.conf, or whatever file used by Debian to configure the ALSA driver, to define the Loopback as card 0. That way, all the ALSA program will access the loopback by default. Of course, jackd must be running all the time for that to be useful. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] VirtualBox and VST
I'm listening to music from an AROS virtual machine in VirtualBox. The audio setup is the following: AROS - ALSA (loopback) - zita-a2j - JACK VirtualBox has no direct support for JACK. A bug was opened 3 years ago asking for jack support https://www.virtualbox.org/ticket/6049 This seam pretty hopeless, unless someone competent enough, which I am not, contribute with some patch. However, when listening to music, it works fabulous with my setup. The main advantage of VirtualBox is that the guest OS is really installed in a virtual machine, and any software compatible with this OS can be installed and will run. VirtualBox is also a little bit faster than wine. So my question is, are there anyone who tested VirtualBox with windows and some VST? Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] 4-6 or 8 cores ??
Le Mon, 24 Jun 2013 15:19:45 +0200, IOhannes m zmoelnig zmoel...@iem.at a écrit : his very well matches my personal experience, that since the advent of PIII/800MHz i never had any more performance problems in my realtime applications. For me, a multi-cores machine is a must. In one hand, jack1 on a 32 bits single core machine and a rt kernel, give me very little less latency, than jack2 on a 64 bits 4 cores machine and a regular kernel, with rt enabled via cgroups. Both machines have the maximum amount of RAM they can handle and are running fvwm-crystal as desktop. On the other hand, this last machine give me the opportunity to be able to do whatever I want, as example run a server, have emerge that compile hugin or libreoffice, and run rt applications, all that at the same time on the same machine. To do the same with a single core machine, I must have a double boot with 2 kernels, a rt one for the audio applications, and a non rt one for the server and emerge (I don't try it with a cgroup enabled kernel). Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] (Modular) Synth and Clipping
Le Sun, 16 Jun 2013 12:13:30 +0100, John Rigg lad...@jrigg.co.uk a écrit : On Sat, Jun 15, 2013 at 11:33:45PM +0200, Dominique Michel wrote: An output transformer will saturate if the frequency is low enough, but the signal level required to saturate it is directly proportional to frequency. In a properly designed guitar or bass amp there will be some transformer distortion at the lowest frequencies but not much above that. If you lowered the frequency enough to fully saturate the transformer it wouldn't sound very good, as you say. (I design guitar amps among other things). Me too, and I repair them too. I was talking here about cheap power transformers used in some brands of commercial guitar amplifiers, not about their output transformers. The main frequency is low enough to easily saturate them when they are not properly dimensioned, and this saturation will go through everything to the speaker. Power transformer saturation only occurs if the voltage applied to the primary is too high. It is not affected directly by the load on the transformer. This is true for a transformer that is not or normally loaded. But when it is overloaded, we can get a behaviour similar to a coil: the saturation is fixed by the current, not by the voltage, due to the knee of the hysteresis curve. That imply the voltage drop will not only be a function of the resistive losses, but also of the saturation of the flux in the iron. A typical example are the old Peavey Mace, good transistor preamp and driver stage, 6x6L6 for the output, but a too small power transformer to drive such a power (160 w RMS), and a bias circuit for the power stage that kill the dynamic when it is in saturation. The power transformer is definitely too small to drive the tubes at full saturated volume. I measured such an amp, the maximum power is the same with a clean sound and at full saturation. The sound is very good when the power stage is not saturated, but very bad when the power stage is saturated, that not only because of the lack of dynamic, but also because of the saturation of the power transformer. The effect you are describing is due to the internal resistance of the transformer windings and other power supply components, not transformer saturation. When more current is drawn the supply voltage drops due to resistive losses. If there's a tube rectifier the effect will be more pronounced. Some people like that effect but not me. I agree that power transformers in many commercial designs are undersized. The Mace have silicon rectifiers. And the supply voltage drop on the output transformer was at least of 100V, that between the full volume point (160 w with a clean sinus, I know its hard...), and the fully saturated point, when at the same time, the output power was almost the same. At the output, the voltage was dropping with the saturation. I don't think resistive losses alone can explain such a huge voltage drop on the supply voltage. Dominique John ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] (Modular) Synth and Clipping
Le Sat, 15 Jun 2013 14:56:13 +0100, Aurélien Leblond blabl...@gmail.com a écrit : Hi all, In a tentative of giving more personality to the modular synth modules of the avw.lv2 set, I have been looking at clipping. I would like here to discuss here a few assumptions, the fruit of my research and get a few feedback/comments to decide what direction to take. - in some cases (or let say modules of a synth), clipping is implemented more to copie what an analogue system would do than a mandatory part of the algorithm... Let's take an example: 2 sin waves mixed together of amplitude -1/1 will just have an amplitude of -2/2 (as long as they are in phase)... A digital mixer without clipping would be able to cope with that, but an analogue one wouldn't... and that's why the analogue system would clip the signal..right? - What method of clipping is used will give a personality to the module: hard clipping, soft clipping, the method used for soft clipping, etc...right? - Hard clipping is something of the digital world - it doesn't exist in the analogue world... right? As already pointed out, an analogue system with enough headroom won't clip the signal. It is also almost impossible to generalize what will append when an analogue system go in clipping. This will depend on what kind of hardware this is (class A preamp, class A, AB or B amp, ...), on what kind of feedback it use (normal audio amplifier with a lot of feedback, or power operational amplifier in open loop like a guitar amp, ...), on the technology in use (bipolar, j-fet, tubes, ...), on the actual implementation of the whole thing inclusive its supply, and even on the quality or power of the components in some cases. As example, when you push guitar amps in clipping at full volume, half of the clipping you can ear is, with some brands, not the clipping of the electronic, but the clipping of the power transformer. That sounds very bad -:(, and that imply you may have to change often this transformer when such amps are used to play blues or rock like styles of music. Even without going to such extreme cases, the actual implementation, which is always a compromise between money and quality, will determine the sound of any analogue system. And this is the most difficult part to simulate -:) Dominique - Soft clipping will deform any waves of amplitude -1/1 even if it doesn't exceed the accepted threshold, because just before reaching the threshold the algorithm will take over and softly make the signal reach the maximum amplitude and keep it there until the original signal goes back under a set threshold.right? - Is there a preferred stage for clipping? In the case of a filter, should we clip before filtering, after or both? Or are all these options valid and that's what will give an additional personality to the filter? Thanks in advance for any comments! Aurélien ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Problem with recent hdspm, alsactl and systemd
Le Thu, 13 Jun 2013 22:02:48 +, Fons Adriaensen f...@linuxaudio.org a écrit : Hello all, Hello Fons, I wonder if any other users have experienced this problem and how they handled it. This has occured three times when doing an fresh Archlinux install on a system using the RME MADI cards. There seems to be something in the combination of recent versions of the driver and alsactl that leads to alsactl freezing when the configured (external) clock source for the card is not available. The 'freeze' seems to be quite deep: it's impossible to kill the process (even while that process is still a child of e.g. the xterm from which it was launched, and not of PID 1). Any other process trying to access the sound card (e.g. jackd) hangs in the same way. This also means that when doing a poweroff or reboot systemd will hang on the 'alsactl store' service, and the only option is a power cycle. An added difficulty when trying to resolve this (things will be OK once you have the correct /var/lib/alsa/asound.state) is that recent systemd doesn't allow to disable or enable the alsa store/ restore services easily (why not ?), you have to manually edit some symlinks in order to do that. I don't know systemd at all. As a temporary workaround for alsa store/restore, maybe you can mask the module in /etc/modprobe.d/blacklist.conf and load it later. Note: if this happens to be a driver problem, please do NOT revert to the ancient behaviour of silently changing the clock source to 'internal' when the external clock is not available. I DO still expect to see opening the device fail if the external clock isn't present, as has been the case for some time. The thing that shouldn't happen is that alsactl chokes on this condition - it didn't before so it shouldn't have to. Ciao, -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Problem with recent hdspm, alsactl and systemd
Le Fri, 14 Jun 2013 10:35:35 +0200, Dominique Michel dominique.mic...@vtxnet.ch a écrit : Le Thu, 13 Jun 2013 22:02:48 +, Fons Adriaensen f...@linuxaudio.org a écrit : Hello all, Hello Fons, I wonder if any other users have experienced this problem and how they handled it. This has occured three times when doing an fresh Archlinux install on a system using the RME MADI cards. There seems to be something in the combination of recent versions of the driver and alsactl that leads to alsactl freezing when the configured (external) clock source for the card is not available. The 'freeze' seems to be quite deep: it's impossible to kill the process (even while that process is still a child of e.g. the xterm from which it was launched, and not of PID 1). Any other process trying to access the sound card (e.g. jackd) hangs in the same way. This also means that when doing a poweroff or reboot systemd will hang on the 'alsactl store' service, and the only option is a power cycle. An added difficulty when trying to resolve this (things will be OK once you have the correct /var/lib/alsa/asound.state) is that recent systemd doesn't allow to disable or enable the alsa store/ restore services easily (why not ?), you have to manually edit some symlinks in order to do that. I don't know systemd at all. As a temporary workaround for alsa store/restore, maybe you can mask the module in /etc/modprobe.d/blacklist.conf and load it later. Obviously, this will not work with alsa store. Note: if this happens to be a driver problem, please do NOT revert to the ancient behaviour of silently changing the clock source to 'internal' when the external clock is not available. I DO still expect to see opening the device fail if the external clock isn't present, as has been the case for some time. The thing that shouldn't happen is that alsactl chokes on this condition - it didn't before so it shouldn't have to. Ciao, -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] build troubles with gtklick
Le Mon, 08 Apr 2013 01:16:37 +0200, Jörn Nettingsmeier netti...@stackingdwarves.net a écrit : hi dominic! first of all, thanks for sharing your tools - klick has saved the day by adding a much-needed jack-transport aware metronome to a sooperlooper setup. now i'm a lazy bastard and want to use gtklick, but even though it compiles and installs fine, it barfs when i start is, like so: nettings@kleineronkel:/usr/lib/python2.7/site-packages/gtklick gtklick Traceback (most recent call last): File /usr/bin/gtklick, line 14, in module from gtklick.gtklick import GTKlick File /usr/lib/python2.7/site-packages/gtklick/gtklick.py, line 30, in module import klick_backend File /usr/lib/python2.7/site-packages/gtklick/klick_backend.py, line 12, in module import liblo ImportError: /usr/lib64/python2.7/site-packages/liblo.so: undefined symbol: lo_address_new_with_proto i have tried both liblo-0.26 and current liblo svn, no luck. now the python paths in this openSUSE tumbleweed install are a horrible mess, with three different python versions and libs in /usr/lib, /usr/lib64, and /usr/local/lib64. but they all seem to be found, and i made sure that the liblo.so mentioned in the error message is actually the one from your pyliblo package (by copying it manually). i removed the build directory of pyliblo for each try, and also recreated liblo.c via cython. how do i proceed to fix this? Here on gentoo, gtklick depend on klick with osc support. And liblo (liblo-0.26 here) is for osc support. Are you sure klick have osc support enabled? Dominique best, jörn -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] build troubles with gtklick
Le Mon, 08 Apr 2013 01:16:37 +0200, Jörn Nettingsmeier netti...@stackingdwarves.net a écrit : hi dominic! first of all, thanks for sharing your tools - klick has saved the day by adding a much-needed jack-transport aware metronome to a sooperlooper setup. now i'm a lazy bastard and want to use gtklick, but even though it compiles and installs fine, it barfs when i start is, like so: nettings@kleineronkel:/usr/lib/python2.7/site-packages/gtklick gtklick Traceback (most recent call last): File /usr/bin/gtklick, line 14, in module from gtklick.gtklick import GTKlick File /usr/lib/python2.7/site-packages/gtklick/gtklick.py, line 30, in module import klick_backend File /usr/lib/python2.7/site-packages/gtklick/klick_backend.py, line 12, in module import liblo ImportError: /usr/lib64/python2.7/site-packages/liblo.so: undefined symbol: lo_address_new_with_proto i have tried both liblo-0.26 and current liblo svn, no luck. now the python paths in this openSUSE tumbleweed install are a horrible mess, with three different python versions and libs in /usr/lib, /usr/lib64, and /usr/local/lib64. but they all seem to be found, and i made sure that the liblo.so mentioned in the error message is actually the one from your pyliblo package (by copying it manually). i removed the build directory of pyliblo for each try, and also recreated liblo.c via cython. how do i proceed to fix this? python is a mess in itself because we have python 2 and 3, and the shebang of many python programs is set as #!/usr/bin/python, which doesn't tell the system which version to use. You have to adjust the shebangs so that the scripts will use the correct version. Something like #!/usr/bin/python2.7 Dominique best, jörn -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OT: Bitwig beta for Linux reviewed
Le Sat, 09 Mar 2013 11:23:39 +0100, Ralf Mardorf ralf.mard...@alice-dsl.net a écrit : As an Ubuntu and Arch user, I'm also very sceptic about the idea to provide Ubuntu packages or an USB stick solution only. On Ubuntu Studio lists all kinds of rumors about Ubuntu's future are discussed. At the moment the situation for Ubuntu already is borderline. Regards, Ralf And what about a gentoo package ? ... Best, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] OT: Bitwig beta for Linux reviewed
Le Sun, 10 Mar 2013 12:56:39 +0100, Ralf Mardorf ralf.mard...@alice-dsl.net a écrit : On Sun, 2013-03-10 at 12:35 +0100, Dominique Michel wrote: Le Sat, 09 Mar 2013 11:23:39 +0100, Ralf Mardorf ralf.mard...@alice-dsl.net a écrit : As an Ubuntu and Arch user, I'm also very sceptic about the idea to provide Ubuntu packages or an USB stick solution only. On Ubuntu Studio lists all kinds of rumors about Ubuntu's future are discussed. At the moment the situation for Ubuntu already is borderline. Regards, Ralf And what about a gentoo package ? Dominique, this would be good. I'm not using it myself, but Gentoo is a good alternative to Ubuntu. I guess Gentoo is similar as Arch. I haven't seen that they provide or will provide a Gentoo source. It is enough if they provide a source tarball. Beside the sources, all that gentoo need is a script called ebuild. This ebuild is used by portage to download, decompress and compile the sources, as well than to install the program. I guess than, like with most proprietary software, we will never get the sources... Unfortunately, software like the ati and nvidia drivers are exceptions, not the rule, with proprietary software. Using gentoo was, for me, the result of many years with GNU/Linux. I try/used many other distributions, and if they are easier to install, a gentoo successful install will work and will be definitely easier to manage on the long run, especially when, like many of us, I am using multiple repositories (overlays for gentoo). That said, I never try arch. What I know is that arch do have an outstanding wiki. The main gentoo disadvantage is that compiling every thing can be very stressing for the hardware. You will need good quality hdd and RAM on the long run. Also, using a rt kernel with portage is not recommended, this can lead to very strange bugs. This is why I am using the gentoo-sources kernel with rt enabled trough cgroups. An alternative is to use one kernel with portage and the rt kernel for audio work. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and CPU stress testing
Le Sat, 2 Mar 2013 15:47:00 +, Harry van Haaren harryhaa...@gmail.com a écrit : Dominique: I've not tried your suggestion yet. Perhaps later if I have time. A little update. I succeeded to crash amule on my 4 core system. Same behaviour: amule is using 100% processor on 1 core, eat all the ram (8 GB), swap like hell and crash. During swapping, the system was so slow that it was unusable (latency for a mouse click around ~30 seconds or so). Also, the only thing that crashed with amule was mplayer and jackdbus. This was not with a rt kernel, but with the gentto sources with cgroups configured for rt (CONFIG_RT_GROUP_SCHED) and no other cgroups policy. So, jack2 crash easily on my 4 core system with a cgroup enabled kernel than jack1 on my old 1 core system with a rt kernel. That's too many variables... so more test is needed in order to know for sure if the cause of this jack2 crash is the huge swapping or something else. Someone know the impact of swapping on jack? I think than to compile hugin is a better test, it will load the system without swapping but with a very high processor use on all the cores. -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and CPU stress testing
Le Fri, 1 Mar 2013 11:41:29 +, Harry van Haaren harryhaa...@gmail.com a écrit : Hey all, I'm currently attempting to stress test my setup of -rt kernel, rtirq scripts, and a Jack client program I've been working on. So my idea is to create a script that runs the programs, and also a cpu-load generating program (cpuburn or alternative). Then collecting stats based on Xruns, % DSP load, etc. I intend to show (trough brute force) that an application is RT capable on machine X with a latency of Y ms. Of course this won't be 100% representative, but the stats will show some RT-safe-ness. Has anybody done this kind of profiling / stress testing with JACK before? Hints / tips / advice / etc welcomed! -Harry On my old mono-processor machine, the following was working very well. Start jackd and some other software that will load it. Start amule and begin to download a lot a files (more you can, faster amule will crash). Amule will consume all the cpu under a very long time. On my mono-processor with a rt kernel optimized for audio, jackd was runing without any kind of problem at the same time than amule. The things begin to be very bad when amule will start. This begin with ed2k-kademilia that get lost, consume all the ram and begin to swap like hell until it crash. During the swapping, jackd was working. But, you have 2 possibilities on a mono processor machine: the system will crash with ed2k or not. When the system was not crashing, a lot of other software was crashed, inclusive parts of fvwm. But in most cases, jackd was one of the surviving pieces of software. Of course, when the system was crashing, jackd was crashing too... Only the power button was still working. On a multi-processor, this behaviour of amule is much more difficult to get, and even if you success to crash it, it will not be a problem for the rest of the system. Also, amule act like a server, which need the inverse optimisation than jackd. jackd is about low latency, a server is about throughput. # # # # # On my multi-processor machine, the best stress test I made was to compile hugin.http://hugin.sourceforge.net/ The 4 cores of my box get very busy with it (around 100 % and a lot of disk accesses). I use gentoo, portage compile every thing, and this software is the most cpu intensive I know to compile. libeoffice take much longer to compile, but it is less cpu intensive. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK and CPU stress testing
Le Fri, 1 Mar 2013 18:01:21 +0100, Dominique Michel dominique.mic...@vtxnet.ch a écrit : The things begin to be very bad when amule will start. This begin with ed2k-kademilia that get lost, consume all the ram and begin to swap like hell until it crash. Sorry, must be: The things begin to be very bad when amule will begin to crash. ... -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
Le Thu, 07 Feb 2013 21:21:59 +0100, Kjetil Matheussen k.s.matheus...@notam02.no a écrit : William Light: it's interesting to me that free (source and/or beer) music software on OSX and windows has come further than it has on Linux. off the top of my head: http://psycle.pastnotecut.org/portal.php http://www.buzzmachines.com/ I'm very interested in knowing what you're missing from Psycle and Buzzmachines that Radium doesn't have... This is not related to any of the software you mention, but what I am really missing in linux audio is the ability to plug-in my guitar (or another instrument), play some melody, and get the corresponding MIDI notes messages in real-time. As the timbre will differ from one instrument to another, and even from a player to another, such a tool should provide a visual way to setup the parameters, that in order to make it easily usable. Is is a few applications that claim to be able to do that. By example guitarix http://linuxaudio.org/mailarchive/lau/2011/1/7/177338 but in practice, it is total unusable. Quote: Guitarix offers this, Given, you play with good intonation/a well tuned instrument, it works OK. I was never able to make it work even with a well tuned guitar. In the past, I done such a rt conversion on a dsp. It was working very well but need some parameters to be carefully chosen. The only way to chose those parameters are with a visual signal analysis. The timbre of an instrument is unique, vary with the time and with the play. I used a memory oscilloscope to do this analysis. I am a lazy bastard that also have a real life, so I never managed to learn enough C/C++ in order to translate my dsp56k program into a GNU/linux software. Some said this would be a piece of cake, but that's not to me. The algorithm is very simple. The incoming signal need to be rounded in order to reject the false maximums that can arise (look at the signal of a good simple humbuking microphone and you will show them) (this will reject the high frequencies and is very simple and fast to implement). This is done with a simple arithmetic mean on the successive input samples. 1 parameter here: the samples number. Another and obvious parameters is the input threshold level. In order to easily adjust those 2 parameters, a visualisation GUI is the best option. It have to show both the incoming signal and the same signal after the average operation. It would be best if it would work like a memory oscilloscope, that is define some threshold and time period the user want to acquire when some incoming signal is detected, acquire the samples into a ring buffer in a one shot way, and display them with the ability to change the x axis period and offset. As a bonus, this will be the best oscilloscope using an audio card on linux. At that point, 2 separated software can even be made. And yes, I am missing too a good memory oscilloscope using the audio card on linux. I know an audio card will never provide the sampling frequency of a LeCroy, but beside the sampling rate, a GNU/linux oscilloscope using the audio card is able to provide a lot of the, if not all, advanced features of a real memory oscilloscope. After the average is done, and concurrently to it, the program find 2 consecutive maximums of same sign of the signal. A simple comparison ( or depending to the sign) of the consecutive samples is enough to do that. The period of the signal is represented by the number of samples that separate those 2 consecutive maximums. The program know the sampling frequency, so, a table can be made with the values of the MIDI notes for different sampling count intervals, and a simple read of this table from the number of samples between 2 consecutive maximums will give the corresponding MIDI note. The worst case scenario depend on the lowest note that will be played. The time to find the note = the period of the note + the time between 0 and the first maximum of the signal. I don't know any faster and simpler algorithm to do that. Dominique P.S.: If you wait for me to adapt this software to GNU/linux, you will wait much longer than if you, or someone else, do it. I try several times, but I never managed to get enough time, to learn the C, and like my life is going, both privately and professionally, this will unfortunately not append in a foreseeable future. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
Le Wed, 6 Feb 2013 08:09:01 -0500, Thomas Vecchione seabla...@gmail.com a écrit : These are just a couple of examples. Documentation in general just needs to be rethought as a community I think. But noone will ever be happy with it, so maybe I am just a grumpy old coot telling you youngins to get off my lawn as this has been gone around many times:) Seablade For the French speaking linux audio community, we have LinuxMAO http://linuxmao.org/tikiwiki/tiki-index.php which is a community driven site with a wiki and a forum. The wiki is for the documentation. The forum is used both for linux (audio) related questions which are not answered/understood in the wiki, and for questions about the content of the wiki. The wiki is focused about using linux to make professional audio, and it is a section into the forum about audio development. I think than to have both a wiki and a forum at the same place is the best option. In practice, it work very well even if it is not perfect. To have such a site is very valuable for the community. This is not the first time we talk about documentation on the LAD, and I think it would be very valuable for the community if an English or multi-languages site with both a wiki and a forum could be made. A solution can be to extend LinuxMAO with English sections on both the wiki and the forum, and why not other languages. I contribute on a more or less regular basis, but I am not a site admin. So I have no idea how they would react to such a proposition, but they are open minded guys. And someone that doesn't try is sure of only one thing: to get nothing. I am also not sure if the LAD is the good place to talk about this in the perspective of making such a site. Maybe lists like the LAU or alsa-users are more appropriate. Or cross-posting to those 3 lists and jack-devel too. My 2 centimes, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] So what do you think sucks about Linux audio ?
Le Tue, 05 Feb 2013 09:58:14 -0500, Dave Phillips dlphill...@woh.rr.com a écrit : Greetings, I've been reading a lot of negative (read: vitriolic) commentary about the world of Linux audio development and applications. I won't bother to say where, just the usual places will have to suffice. Of greater interest to me is the commentary itself - it seems to boil down to the following plaints and lamentations (in no particular order) : Too many distros. Too many audio-optimized distros. Not enough native plugins, esp. instruments. Inconsistent support for VST/VSTi plugins. Too many unstable/unfinished applications. Too many standards (esp. wrt plugins). Poor external/internal session management. Poor support for certain modes of composition (think Ableton Live). Lack of support for contemporary hardware. Confusion re: desktops, and GUI toolkits. Too difficult to set up audio system. JACK is a pain. Too much conflict/fragmentation within the development community. Every OS is different. The main difference between linux and the other OS is than we don't have, on linux, big tools that make every thing but the coffee. We have instead a huge collection of tools, each ones of them making one thing, and sometime we have duplicated tools, which make possible to follow different ways. That imply we need documentation to guide a newbie or a non geek musician trough all those tools, showing them which tool can make what and how to set up those tool, and at least as important, which tool, or which chain of tools, can be used to make a given task. I also think we must have in mind than most peoples are not rational. They are more receptive to publicity than to rational thinking or technical concepts. Musicians and the like are not exceptions. This is why at the first place, they feel bad instead of fell free when they show different (audio optimized) distributions, different GUI, WM, desktop, sound servers, plugins API, ... And this is true also with linux audio. Sometime (often), we have different ways to make a task, and many peoples new to linux feel very bad with this situation. But that's what GNU/linux is about: freedom like in free speech. We don't make publicity. The only way to address that lack of publicity is to make easy to follow documentation which explain how to do things, and explore the different possibilities an user can encounter to make a given task, so they will eventually begin to feel free and fly on the linux audio world. Dominique I'm not so interested in comments on the commentary, I have my own, but say what you will about the list. I figure that most denizens of these lists already have ready replies and responses to these and other criticisms, many of which have been voiced here previously. What I'm more interested in is what *you* think is missing most or just plain wrong about the situation. Please, try to speak your piece without flames or dissing other developers and/or their work. Frankly speaking, I've had enough of that crap, and I'm most thankful these days for such forum amenities as mute user and autodiscard, along with the standard filters found in mail clients. aside I'm reminded of John Cage's comments regarding the behavior of the NY Philharmonic when they destroyed his equipment during the premire of Atlas Eclipticalis, something to the effect that his concerns had ceased to be musical and had become social, i.e. that he had to figure a way to allow people to be free yet behave themselves with respect towards the common goal (e.g. Cage's music and property). I'm going to guess that he was still working on that up to his death. /aside So, in your honest and bold opinion as user and/or developer, what do we lack most and what can we do without that we already have ? Please feel free to expand your remarks as you like. I'm planning an article on the topic and will likely use selected comments, subject to approval of course. Best, dp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What KvR didn´t understand.
Le Mon, 07 Jan 2013 16:24:10 +0100, Ove Karlsen ove.karl...@paradoxuncreated.com a écrit : To all people who want this trash gone, and their failure to understand decent thinking, read my research, establish islamic laws, and they will be executed. And decent people, and their families can live in peace. .. after the dead or in some other life after the dead. This is the credo of all the religions. The only true problem is that I am living here and now, not in some hypothetical place conjugated to the hypothetical future of the unconditional of the more-than-perfect! This is why the only God I trust is my own Sacred Spirit! Computer science is about rational thinking. Religion is about non-rational superstitions. You are mixing all together into a totally non-understandable thinking. So, wake-up and stay on focus: this list is about linux audio development, not about some religious path to the Armageddon. For this last subject (the Armagedon dear to all religions), it is plenty of list and forums elsewhere on the internet. It took centuries in Europa to get ride of all those religious dictatorships! Sweden was the last European country to separate the state from the religion in 1923. Peace Be With You. without idiotic religious dictatorship! Join you own Sacred Spirit and the peace will be with you! -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] List moderation (was: What KvR didn´t understand)
Le Mon, 07 Jan 2013 19:48:52 +0100, Marc-Olivier Barre ma...@marcochapeau.org a écrit : On 2013-01-07 15:57, Paul Davis wrote: On Mon, Jan 7, 2013 at 9:46 AM, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: On 1/7/2013 3:34 PM, Brett McCoy wrote: On Mon, Jan 7, 2013 at 9:25 AM, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: I would like to take the oppourtunity to reply this with, that the psychiatry has become such an instritution of abuse, that bullies online have started using their phrases. lots of stuff snipped Can we just stick with discussions of Linux audio? And Personally, to idiots like these, I would like to say: www.worshipthediscusting.com [1] is for you. This incredibly offensive - Brett was extremely polite to your off-topic stuff. You've just been needlessly and excessively insulting. I don't know what you are doing on LAD, but I will not read any further messages from you. Hello dear LADs, Well, I don't speak much on the lists nowadays, but I will just say this: If people get offended by any kind of mail of the nature we just experienced please write to the moderation email right away (mail address can be found on the list website). I don't do a lot for the mailing lists these days, but I can be fast reacting on those. Moreover, it allows me to go read the list for a bit of entertainment, and damn, this one was good. although I am still wondering if the guy is for real... I thought those were extinct or had no internet :) PS: as you might have seen, Robin was faster than I and turned on the guys moderation bit. I would have gone for a pure ban, but hey ! Robin is a nicer guy than I am I guess :D Cheers all ! This guy collected emails here. In consequence, I banned him from my mail client. Instead of wasting his time, he should try some psychotherapy or go for a walk. Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Radium V1.9.1
Le Sun, 11 Nov 2012 15:37:13 +0100, Florian Paul Schmidt mista.ta...@gmx.net a écrit : On 11/10/2012 08:12 PM, Kjetil Matheussen wrote: Source code: http://dl.dropbox.com/u/4814054/radium-1.9.1.tar.gz Hi, building from source sadly fails, too. make packages runs through fine, then during build: Same error, here on gentoo: g++ Qt/Qt_MainWindow.cpp -c `cat buildtype.opt` -DNOPAUSEPLAY -Ibin/packages/gc-7.2/include -IQt/ -I/usr/include/python2.7 -DGUIISQT -Imidi/rtmidi -DUSE_GFX_OP_QUEUE -Werror=array-bounds -DUSE_QT_VISUAL=1 -DUSE_GTK_VISUAL=0 -DUSE_QT_REQTYPE=1 -DUSE_GTK_REQTYPE=0 -DUSE_QT_MENU=1 -DUSE_GTK_MENU=0 -DUSE_VESTIGE=0 -DUSE_QT4 -DUSE_QIMAGE_BUFFER=1 -DQT_SHARED -DQT3_SUPPORT -I/usr/include/qt4 -I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtSql -DQT_NO_OPENGL g++ windows.o window_config.o list.o vector.o hashmap.o song.o blocks.o block_insert.o block_split.o block_delete.o block_properties.o tracks.o localzooms.o control.o lines.o font.o track_insert.o track_onoff.o settings.o notes.o notes_legalize.o wblocks.o wtracks.o sliders.o gfx_wblocks.o gfx_wblocks_reltempo.o gfx_statusbar.o gfx_tempotrackheader.o gfx_upperleft.o common.o gfx_wtracks.o gfx_wtrackborder.o gfx_wtext.o gfx_text.o gfx_lines.o gfx_point.o gfx_op_queue.o eventreciever.o reallines.o notestext.o trackreallines.o clipboard_range.o clipboard_range_calc.o clipboard_range_copy.o clipboard_range_paste.o clipboard_range_cut.o transpose.o backwards.o invert.o glissando.o pitchexpand.o clipboard_track_copy.o clipboard_track_paste.o clipboard_track_cut.o clipboard_tempos_copy.o clipboard_localzooms.o clipboard_block_copy.o clipboard_block_paste.o quantitize.o mouse.o mouse_wtrack.o mouse_wtrackheader.o mouse_tempoheader.o mouse_wtrackborder.o mouse_temponodeborder.o mouse_fxarea.o mouse_vellinenode.o mouse_vellineend.o mouse_vellinestart.o mouse_fxnode.o mouse_quantitize.o mouse_reltemposlider.o tbox.o area.o range.o debug.o memory.o placement.o t_gc.o cursor.o cursor_updown.o subtrack.o velocities.o pixmap.o scroll.o blts.o realline_calc.o gfx_subtrack.o LPB.o gfx_wtrackheaders.o gfx_wtrackheader_volpan.o gfx_slider.o reallines_insert.o gfx_shrink.o gfx_shrink_t.o gfx_request.o nodelines.o nodeboxes.o instruments.o patch.o fxlines.o fxlines_legalize.o blocklist.o scroll_play.o gfx_tempocolor.o reltempo.o temponodes.o tempos.o time.o time2place.o mouse_temponodes.o temponodes_legalize.o Ptask2Mtask.o player.o scheduler.o PEQrealline.o PEQmempool.o PEQblock.o PEQnotes.o PEQcommon.o playerclass.o player_startstop.o PEQvelocities.o PEQ_calc.o PEQfxs.o player_pause.o PEQ_type.o PEQ_calc_64bit.o PEQ_clock.o disk.o disk_fxs.o disk_wblock.o disk_localzooms.o disk_track.o disk_fx.o disk_fxnodelines.o disk_wtrack.o disk_temponodes.o disk_tempos.o disk_song.o disk_velocities.o disk_block.o disk_placement.o disk_stops.o disk_playlist.o disk_root.o disk_notes.o disk_lpbs.o disk_windows.o disk_warea.o disk_save.o disk_load.o disk_instrument.o disk_patches.o disk_slider.o undo.o undo_notes.o undo_fxs.o undo_temponodes.o undo_tempos.o undo_lpbs.o undo_notesandfxs.o undo_reallines.o undo_tracks.o undo_range.o undo_blocks.o undo_trackheader.o undo_reltempomax.o undo_maintempos.o undo_block_insertdelete.o undo_block_mergesplit.o undo_reltemposlider.o undo_playlist.o undo_patch.o undo_patchvoice.o undo_patchname.o undo_chip_position.o Qt_visual.o GTK_visual.o Qt_Main.o Qt_endprogram.o Qt_EventReceiver.o Qt_colors.o Qt_Menues.o Qt_Fonts.o Qt_ReqType.o Qt_PopupMenu.o qcolordialog.o Qt_Bs_edit.o Qt_instruments.o Qt_PluginWidget.o Qt_MyQSlider.o Qt_SliderPainter.o Qt_memory.o Qt_path_resolver.o Qt_settings.o Qt_MainWindow.o GTK_ReqType.o GTK_PopupMenu.o Qt_soundfilesaver_widget_callbacks.o Qt_Semaphores.o radium_wrap.o api_common.o api_keyplay.o api_keyplayedit.o api_navigate.o api_noteedit.o api_support.o ad_noteadd.o wrapfunclist.o api_trackonoff.o api_zoom.o api_notemanipulate.o api_play.o api_clipboard.o api_undo.o api_various.o api_instruments.o api_requesters.o posix_settings.o posix_Player.o X11_keyboard.o X11_error.o X11_disk.o X11_Qtstuff.o disk_midi_fx.o disk_midi_i_plugin.o midi_fx.o midi_i_plugin.o midi_playfromstart.o midi_rtmidi.o RtMidi.o midi_i_input.o midi_menues.o zita_rev.o stk_flute.o stk_bowed.o stk_blow_bottle.o stk_bass.o stk_blow_hole.o stk_brass.o stk_clarinet.o stk_flute_stk.o stk_glass_harmonica.o stk_harpsi.o stk_modal_bar.o stk_NLF_eks.o stk_NLF_fm.o stk_piano.o stk_saxophony.o stk_sitar.o stk_tibetan_bowl.o stk_tuned_bar.o stk_uni_bar.o stk_voice_form.o faust_tapiir.o faust_system_eq.o faust_system_lowpass.o faust_system_lowshelf.o faust_system_highshelf.o faust_system_delay.o faust_multibandcomp.o audio_instrument.o SoundProducer.o Jack_plugin.o Bus_plugins.o VST_plugins.o Ladspa_plugins.o Sampler_plugin.o FluidSynth_plugin.o
Re: [LAD] [ANN] Radium V1.9.1
Le Sun, 11 Nov 2012 16:30:43 +0100,
Kjetil Matheussen k.s.matheus...@notam02.no a écrit :
Florian Paul Schmidt mista.tapas at gmx.net
fluid_sys.c:(.text+0x10fc): undefined reference to `readline'
bin/packages/fluidsynth-1.1.6/src/.libs/libfluidsynth.a(libfluidsynth_la-fluid_cmd.o):
In function `fluid_shell_run':
fluid_cmd.c:(.text+0x1b06): undefined reference to `add_history'
Thanks, fixed in git:
https://github.com/kmatheussen/radium/archive/master.zip
Thank you, it work fine now.
However, I found 2 minor issues. I am making an ebuild to install it,
and found 2 minor issues. At the beginning of Makefile.Qt, it is
libdir = $(prefix)/lib
but on my multilib system, ${libdir} is /usr/lib64
libdir ?= $(prefix)/lib
must be right to be able to manage $libdir in a multilib system.
The second issue is, after installing radium with portage, I get an
executable in /usr/bin/radium, and when I run it, I get:
/usr/bin/radium: ligne 2 :
cd: /var/tmp/portage/media-sound/radium-1.9.1/image//usr/lib64/radium:
Aucun fichier ou dossier de ce type
/usr/bin/radium: ligne3: ./radium: Aucun fichier ou dossier de ce type
In English: No file or directory of this type.
After changing this line into
cd /usr/lib64/radium
radium is working fine.
In the ebuild, the make packages line look like:
emake DESTDIR=${D} PREFIX=/usr libdir=/usr/$(get_libdir)
BUILDTYPE=RELEASE OPTIMIZE=${CXXFLAGS} packages
${D} is the root of the sandbox where portage will build radium.
$(get_libdir) will echo lib64 in my case.
${CXXFLAGS} are the main CXXFLAGS for the system as defined
in /etc/make.conf on gentoo. They are safe flags that should work in
any cases.
The make install line look the same:
emake libdir=/usr/$(get_libdir) DESTDIR=${D} PREFIX=/usr install
Dominique
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
We have the heroes we deserve.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] Radium V1.9.1
Le Sun, 11 Nov 2012 21:00:41 +0100,
Dominique Michel dominique.mic...@vtxnet.ch a écrit :
${D} is the root of the sandbox where portage will build radium.
${D} is the root of the sandbox where portage will install radium
before to copy the files in their final location.
Dominique
--
We have the heroes we deserve.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Laborejo 0.4 release
Le Tue, 6 Nov 2012 18:36:41 +0100, Nils Gey i...@nilsgey.de a écrit : A wild crosspost appears! snip This is the release of version 0.4 Download: https://github.com/nilsgey/Laborejo/tarball/0.4 In order to make a gentoo ebuild, I need a direct link on the tarball. Can you provide it? Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux Audio 2012: Is Linux Audio moving forward?
Le Wed, 10 Oct 2012 12:24:22 +0400, Louigi Verona louigi.ver...@gmail.com a écrit : Hey fellas! Would like to present an article I've written. Mostly wrote it to start a conversation and hear what others have to say on the subject. http://www.louigiverona.ru/?page=projectss=writingst=linuxa=linux_progress You can comment here or on my textboard (which does not require registration). Interesting reading. From an user perspective, I have been used GNU/linux from quite some time now (back from my 386 box), and I have seen very things to appear like ALSA and JACK. In recent years, the biggest improvement was jack2 on multiprocessor machines. It is just much more easier to get the job done because the processor use is lower. This give us also a better stability at high system load. .But in the same time, I have seen a couple of choices coming, which are not directly related to the linux audio community, but can influence us badly if such idiotic choices are becoming the norm into GNU/linux in the future. More specifically, if I do understand the need for some big corporations for stuffs like policykit and consolekit, I just have no use for them in an audio pro box. So, I don't want them, and the recent decision to include a java script interpreter into polkit (in order to try to make it to become manageable...) will certainly not made me to change my mind: I have other things to do with my time than to learn JS in order to be able to make system administration, and I will not pay for that either. The worst thing with polkit, what is completely idiotic, is than it is a mandatory dependency of gnome. In consequence, when installing any gnome related program, this will install polkit and consolekit, and something as simple and efficient than startx will become broken, because as soon than polkit is installed, it is forcing you to run consolkit in order to be able to launch xorg with your favourite and *kit free wm/desktop. In consequence, my box today is not only completely windows free, but also completely gnome free. The kernel is a terrific tool. It just do its job, and it do it very well. And we have plenty of terrific audio tools. To speak generally, I think than another consequence of such idiotic choices is than we need to keep a close eye on what is going on in userland. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forward?
Le Wed, 10 Oct 2012 23:48:50 +0100, Harry van Haaren harryhaa...@gmail.com a écrit : Replying to nobody in particular but perhaps bringing some new things to the table: I feel there's a lot going on just-under-the-surface of what most of us know about. I presume not everybody here is aware of the advances FAUST has recently made in DomainSpecificLanguage technology. Similary I'm sure there's other projects having successes that I'm not aware of (despite being subscribed to all linux-audio feeds I know exist :) So are these under-the-surface technologies and workflows going to arise into public knowledge? If so, how? The other things I feel is necessary is to bundle the community together: We need to agree on one place to post information: a central hub for linux-audio. This location needs to have a certain appeal for newcomers, where inspiration strikes: YES! With those tools I can achieve exactly what I've wanted for years!! says the now enthusiastic and ISO downloading newcomer. -Harry I fully agree with you. For the French linux audio community, it is Linux MAO www.linuxmao.org that is a wiki with audio related wiki, tutors and forum. We try to keep the it up-to-date. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] rt-kernel and nvidia graphic card
Thank you all folks for your responses. Le Tue, 31 Jan 2012 08:00:22 -0500, Trulan Martin trul...@gmail.com a écrit : For me, on a GeForce6150LE, the only video driver that is really stable on the RT kernel is vesa. The NVidia driver works OK with a non-RT kernel (and the 'threadirqs' boot parameter, rtirq script, etc.), but only on 64 bit. I was not knowing that it is possible to use rtirq with a non-RT kernel. I will experiment that too. The nouveau driver has never worked on my machine with any kernel, ever. After several try, I finally get it to work with a non-RT kernel. It was almost one year ago, but its stability was a calamity with the Geforce 8800 GT. I haven't tried nv in a long time because it gives me pathetically low resolution. Last time I try it was on my precedent machine with a few different RT-kernels, and it give me 1280x1024 without problem (with custom modelines into xorg.conf). The stability was very good even at very high system load. The performance with fvwm-crystal was really good too, jack was almost imperturbable, just the desktop that was slow sometime at high system load. But on my new machine and its quad core phenom, it is much more difficult to slow down the desktop. But, if you want to try the NVidia proprietary driver, it is better to patch the driver souces rather than faking the license in the kernel. See here: http://article.gmane.org/gmane.linux.rt.user/7478 This patch lets the NVidia module build on 3.0 and 3.2 RT kernels. This kernel/driver combination does not work on my machine, unfortunately. But Thanks, I will try it too. OK, so to resume, I have to make 3 kernels, a non-RT for work with portage and gcc (gcc can give wrong results sometime with a RT-kernel https://bugs.gentoo.org/show_bug.cgi?id=20600), and 2 RT, one with the patched nvidia and vesa, and the other with vesa and nv. Ciao, Dominique - Trulan -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] rt-kernel and nvidia graphic card
Hi, I have an asus amd64 PC with a nvidia GeForce 8800 GT graphic card. This PC is working fine with the gentoo-kernel and the nvidia proprietary kernel module. I want to experiment with the rt-kernel. It is 3 modules for the nvidia card. - The nvidia proprietary module, I guess that this is not necessarily a good choice because it will not be patched for use with the rt-kernel. But I am not sure. - The 2 others are with the kernel, nv and nouveau. Which module will be best to use with the rt-kernel? Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Linux Audio Documentaion Effort : (Was Question 0)
Le Mon, 28 Nov 2011 00:31:50 +, Harry van Haaren harryhaa...@gmail.com a écrit : I think some beginner coding documentation on Linux Audio would be a great asset to the community, and I'm willing to contribute to such an effort. As Robin Gareus mentioned in another thread, a FLOSS manual is probably the best way to go for a community effort on documenting. It is a very good idea. Personally I'd be even more enthusiastic about such an effort if some of the veteran Linux audio guys were to get on board and ensure the content is of a high quality. (As I'm a self though programmer, there are some big gaps in my knowledge, and I'd not like to provide bad sample code, or share bad concepts.) I will be very interested because I have some basic skills (basic, assembler, bash) but never get enough time to learn the C/C++ and the other needed skills in order to become an audio programmer on a modern system. I have a working note recognition software (monophonic realtime Audio to MIDI conversion) on a dsp56k, and would like to port it to C/C++ on linux. It will need a GUI in order to be easily usable with so many sound sources (musical instruments) than possible. It is so many things to learn for me (C/C++, JACK, some toolkit, threading, ...) than I never was able to see how to process to learn all that in the little amount of free time I have. A good audio tutorial will be definitely a great asset, not only for me, but also for the whole community. Of course some issues will arise in choosing how to document Linux Audio, and some typical flame topics like GUI toolkits, libraries etc will arise. I have no idea how we can best avoid that issue, except by following the if you think it should be thought that way write the tutorial... the downside of this is that if one tutorial uses toolkit X and the next toolkit Y, the average beginning coder is going to get lost in implementation details and that defeats the purpose of documentation :D A toolkit is about visual presentation and interaction with the core of the software. Whichever toolkit you choose, you will have to learn the same things, but in a different manner. So, I think that you need first to focus on the core and only after look on its interactions with the toolkit. Also, depending to the goal of a given program, the interactions between the core and the toolkit will be more or less deep, and they will interfere on the core more or less deeply. I think that deeper those interactions are, more it will be important to have good coding skills. But the problem to solve will always be the same: a goal to reach, a core and its interactions with a toolkit. Dominique -Harry -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RAUL?
Le Wed, 16 Nov 2011 11:32:58 +0100, Thorsten Wilms t...@freenet.de a écrit : I'm not a fan of capitalism and even less so of long work-days, but it's hard to even think of a better system that takes human nature into account, to not even speak of establishing one. Fpr me, the problem is not to imagine another system of society, but how to archive it in practice. In an ideal society, its goal will be something like to give the means of being happy and have a life in dignity to every one. The economic system will be a tool to archive this goal and nothing more. We can imagine any system of society, the economy will always be a tool to archive some goal. One of the principal problem with capitalism is that the goal is the economy itself. So, in practice, the society doesn't have any goal and our work doesn't have any meaning, at the exception of archiving a goal that is not a goal but a tool. In such a society, I thing that licenses like the GPL make sense, and are definitely a move in the good direction. The ground of this problem is religious. For me, the only transcendence that exist here and now is the transcendence of the human being. That is that unique capacity we have in the creation to think about an issue, here and now, and from that reflection, fix some goals, and always here and now, work to archive those goals. We are the only one creature of the creation that is not living like its ancestors was. But now, we are not in control of the path of the society, this is the economy that is in control. And that's not a good thing because the economy must always be a tool to archive the goal. Also, our economy is like a yo-yo, one day up, the other down. And that's not a good thing either. We can see where we are now with such a system: The most riches countries of the world are facing bankruptcy and the only one economic argument they have left is war. We have the heroes we deserve. For a Christian, and as the name of this religion tell us, the hero is a warrior, the Christ of the apocalypse. Christ was nothing new. In more ancient time, it was Thor and its hammer. Even more ancient, we can find Indra and its lightning (she is the Indian Goddess of war). And so on back to the beginning of Antiquity when the religion ceased to be a personal issue. For me, the hero is simply the worker. Exactly like in the John Lennon song. http://www.youtube.com/watch?v=Ve-mANenpC4feature=related Now, I don't have any recipe. I know what I want : a better world for my children, and I want it here and now because I am living here and now. I am not interested in a better life after the dead, or in another life, or on Mars or another planet of the universe. I want it here and now. I also now that I have to fight for that goal. It is one of the reason why I adopted free software. It is why I am supporting countries like Cuba or Venezuela. It is also why I am supporting the outraged even If I think than they must organize them in order to be able to offer a real and credible political alternative. With other words, we must recover our true transcendental human nature and change our culture of war and money into a culture of peace and respect. I stop here otherwise I will write a book. -:) See you in the streets. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RAUL?
Le Wed, 16 Nov 2011 21:40:56 +0300, Louigi Verona louigi.ver...@gmail.com a écrit : One of the principal problem with capitalism is that the goal is the economy itself. So, in practice, the society doesn't have any goal and our work doesn't have any meaning, at the exception of archiving a goal that is not a goal but a tool. Actually, this is something I can relate to. I don't know if you can say it is about religion, but it is about looking at life from other than a purely financial point of view. It is more than just a financial POV. It is about exploitation. Exploitation of each other and exploitation of the natural resources. Exploitation is the contrary of respect. In a normal human society, human beings will respect each other and respect the environment they are living into. In ours, we are exploiting each others and the natural resources. And not only that, we are also turning all the natural resources we touch in sources of pollution, and that at a very alarming rate. For what? for the money, but not only. It is also about power, power on other human beings. In a society, it is morally impossible to exploit his fellow. It is necessary for it to degrade him to an inferior status in advance. If we take a look at history, capitalism is one system of exploitation among others. It is an historic continuity of such systems of society, continuity that begin with the antiquity. During this period of history appear simultaneously trade, organized warfare, and the religions of domination. At the same period, the women loose their social status and they take revenge: the corollary of the warrior appeared in history, the cuckold is born. -:) All the religions of domination do have dogmas that make possible to create artificial hierarchies. The things become good or evil by nature, or yin or yang by nature, when in fact things just are. Point. But we have the choice. We can take stones and build a house, or we can take the same stones and launch them on our fellows. In both cases the stones just are, and we make a good action in the first case, a bad one in the second. Also, when things just are, it is not possible to make a moral hierarchy between them, because they all are on the same level. But when things are yin or yang, or good or evil, we can make 2 supernatural hierarchies: The first one between the gods, the men and the rest of the creation. It is the moral justification of the blind exploitation of our natural resources and their systematic transformation into sources of pollution. The second one is between the human beings, some become more closer to the gods than the other. It is the moral justification of all kinds of racism and exploitation. Those dogmas do have another inhuman dimension: their unchanging nature. Only the gods can change this Order of Things during the apocalypse (the bible version), or a reborn into another life (confucianism version). In other words: Sheep you are. Sheep you will remain even after being sheared to the bone. If I take a close look at history, and especially at the history of the religions, I just cannot separate the fight against exploitation from the fight against its moral justification: the dogmas of the organized religions. I also thing that, if we don't eradicate the moral justification of exploitation, the only one change we will be able to realize is to replace one more time a society of exploitation by another kind of society of exploitation. Religion must become, like before the antiquity, a personal affair. For that to be possible, the human beings must be aware of their true transcendental nature. That is just the ability to define our own goals, here and now, and to work for their achievement. If we do reach a point in conversation where the need to touch upon such issues will arrive, I think it might be worth doing it. -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LAC 2011
Le Thu, 02 Jun 2011 14:46:14 +0200, Robin Gareus ro...@gareus.org a écrit : Hi *, The LAC 2011 site just ascended. All conference material (proceedings, video recordings, slides, etc) has been made publicly available. http://lac.linuxaudio.org/2011/ We'd like to thank all speakers and everyone who volunteered to make this an enjoyable event; in particular Frank Neumann, John Lato, Victor Lazzarini and special thanks to Jörn Nettingsmeier. enjoy, robin for the LAC-2011 team. Thank you all. The link at http://lac.linuxaudio.org/2011/download/lac2011_jeremy_jongepier_slides.pdf is wrong. I get the following when loading it into xpdf: Error: May not be a PDF file (continuing anyway) Error (15): Illegal character '' Error: PDF file is damaged - attempting to reconstruct xref table... Error: Couldn't find trailer dictionary Error: Couldn't read xref table The file open fine in libreoffice. I guess that the correct extension for this file is .odp and not .pdf Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any package builders here?
Le Wed, 1 Jun 2011 13:49:06 +0200, Nick Copeland nickycopel...@hotmail.com a écrit : I might get flamed for this however GUI should not really be run with rt priority, that is an honour for the DSP engines. There are some reasonable arguments however for leaning on the scheduler with renice for the user interfaces to give them a bit of a bias over other system operations. Admittedly a big topic since the GUI probably sits on top of the windowing system anyway. So I have not used renice on graphics/GUI processes but I have worked on systems where the RT DSP code is happily chewing up 75% of CPU to churn out 32 unified synth voices and the GUI response can then give a bad impression of an application. Renice will help the sometime intensive graphics manipulation code (which is surprisingly close to DSP anyway if you are doing subpixel image transforms with shadow rendering) to get a little more of the now starved system resources. I think than the wm in use can maybe have an impact on the graphical responsiveness. When running a single mono processor, I get up with jack at more than 95% CPU, this with gentoo running a rt kernel, fvwm and the fvwm-crystal theme. Sometime, the graphical response was a little bit slow. A few times, the wm was frozen during one or 2 seconds, even the cursor. But the audio process in JACK was just fine and without any xrun. I was very surprised, this was amazing, like in window$, but without the crash -:) I cannot imagine to do the same with kde or another wm, in fact I don't know if it can be possible. Now, on a multi-processor, I never experimented such a slow down of fvwm, but I didn't use jack with such a high load than before. Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] mp3-player needs sendmail - really?
Le Sun, 29 May 2011 09:11:49 +0200, Jens M Andreasen jens.andrea...@comhem.se a écrit : Anybody got any idea why the realplayer insist on installing sendmail as well? Is it a rootkit, intending to turn me into a spam-node? Or maybe than big brother want to turn you into a little brother node :) The realplayer and its codecs have constant security issues. Hopefully, here on gentoo, it have been removed from portage a while ago -:) http://forums.gentoo.org/viewtopic-t-713051.html. Recent mplayer versions will just be fine instead. Ciao, Dominique /j ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] the future of display/drawing models (Was: Re: [ANN] IR: LV2 Convolution Reverb)
Le Tue, 22 Feb 2011 22:11:27 +, Fons Adriaensen f...@linuxaudio.org a écrit : 2) more and more apps able to take advantage of v-blank sync to reduce computational load due to unnecessary redraws. instead, the whole system will be a lot like a video-framebuffer version of JACK: the vblank interrupt arrives. everything with a surface gets a chance to redraw if it needs to, the surfaces are composited together, and boom, its on the display. Two remarks on this: 1. Syncing updates to the video frame rate of course makes sense, and there is no reason why it couldn't be done in X. All it takes is some support from the driver to generate an event at the right time. 2. But at the same time this is sort of backwards. There is no reason today why a computer display should be driven by a 'video' signal that refreshes the complete screen at a fixed rate. *That* itself is very old technology and completely useless in this age. Another problem is the hardware. All the PC video cards are video driven. That imply than the card have to refresh the whole screen in order to change one pixel. That is not old technology, that is PC technology. At the same time than the first PC was computers like the Amiga or the Atary. In the Amiga, the video card was vectorial, to change one pixel, all that was needed was the new pixel value and its x y coordinates. To change a part of the screen, the Amiga was using vectorial objects called sprites. So, even for complex visual objects, the computational time was much lower than with the video approach, and the 2D on such old machines is still competitive against the 2D on the most powerful PC of today. At that time, 3D was almost non existent. To develop the 3D capabilities, most efforts from the manufacturers was spend on improving the video based cards. Now, the situation is than the 2D part of a video card is so little than the manufacturers are considering to remove it and use the 3D part to get the 2D from the card. I don't get the advantage of this approach for a workstation. A workstation is not about 3D gaming but about making some work. 3D cards are very hungry for electricity, and they will be an overkill for anyone that is not working on some kind of 3D development. The electricity providers will certainly like them very much, but my wallet and the environment don't like them. So, I think than a complete discussion on that matter should include the hardware part, that is how to make power and computational efficient 2D video cards. Dominique Ciao, -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Calculate R M S (Alfs Kurmis)
Le Fri, 18 Feb 2011 21:05:36 +, Fons Adriaensen f...@linuxaudio.org a écrit : On Sat, Feb 19, 2011 at 09:16:32AM +1300, Jeff McClintock wrote: From: Fons Adriaensen f...@linuxaudio.org On Fri, Feb 18, 2011 at 07:36:44AM +1300, Jeff McClintock wrote: With a RMS VU Meter you measure a 1KHz tone as a reference. A contradiction... A VU does not measure RMS, whatever does measure RMS is not a VU. Isn't a VU Meter a standard root-mean-square function followed by a 300ms integration to give it some 'weight'? ...calibrated against a 1kHz tone? No. VU meters were used in the times when audio equipment was using tubes (valves) so they could not use complex electronic processing, at most an amplifier stage to drive a bridge rectifier and a passive moving coil meter. So, ignoring the rectifier threshold, the current driving the meter would be the absolute value of the signal, not the square of it. Such indicators shows the average value of the signal, not the instantaneous value. In case of DC, they are the same, but they are quite differents in case of AC signals like audio. That is why the needle should never exceed -6db when recording with old analog equipment. The exact value you should not exceed depend of the kind of music you are recording. The meter itself is equivalent to a second order lowpass filter, and its response was quite strictly specified. For a steady signal, it should rise to 99% of the final value in 300ms, and overshoot it by 1 to 1.5% before falling back to the real value. The overshoot isn't a detail - it has quite a marked effect on the response. Many software 'VU' meters use a first order lowpass - this doesn't even come close to the response of a the real thing. Ciao, -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Calculate R M S
Le Wed, 16 Feb 2011 19:51:09 +0200,
Alfs Kurmis kallipy...@inbox.lv a écrit :
Hi Experts.
I wanna normalize my sound stream by loudness (energy / pressure /
intensity) , not by peaks.
How i do it ?
Is available Jack plugin for so what ?
What is (we hear as) loudness ?
Loudness is an adaptive filtering that depend on the position of the
volume knob. At full volume, no filtering is done, at low volume, the
low and high frequencies are more amplified than the medium ones.
RMS or +(average) or something else ?
In Audio, that is a mean to express or measure the sound volume.
http://en.wikipedia.org/wiki/Root_mean_square
It is different ways to measure the sound level. For low end home
equipment, the sinus power is used. Such a sound doesn't correspond
well to a real life situation, that is when your are listening to some
music. It can also be very stressful for an amplifier.
A much better way to express the power of a sound equipment, is to use
some kind of white or pink noise instead of a sinus. That is how the
rms power is measured. In such, it doesn't tell anything because you
have to know the condition of the measure (usually the characteristics
of the white or pink noise, and a given rate of distortion) in order to
be able to interpret it.
In practice, the rms power is usually a little bit lower than the sinus
power measured at the same rate of distortion.
Is somewhere available examples how to calculate RMS ?
Is it done simlpe by :
#160;int i, n;#160; double sums, rms;
#160;sums=0.0;#160; n=10;#160; rms=0;
#160;for(i=0; in;i++)
#160;{#160;#160; sums = sums + ( (double)i * (double)i );#160; }
#160;rms = sqrt(sums / n);
#160;printf(#160;#160;#160;#160;#160;#160;#160;#160;#160;
rms = %12.12fnn, rms );
Is so sipmple algo good enough for frequencies 10 kHz ?
How to calculate RMS with hi-precision for frequencies 10 kHz ?
With inerpolation or so ?
What is reference ( 0dB ) RMS for example for 16bit PCM signal 1024
samples ?
#160; sqrt( 1024*(0x7FFF ^ 2) / 1024 )#160; ==#160; sqrt( (0x7FFF
^ 2)#160; ) == 0x7FFF#160;
Is it simple#160; 0x7FFF (32000 dec) ?
How to calc RMS for stereo signal ?
So , or somehow else ?
for(i=0; in;i++)
#160;{#160;
#160;#160; sums = sampleL/2 + sampleR/2;
#160;}
In case operating with float point, what should be a bit
faster,#160; / 2#160; or * 0.5 ?
How to gotta RMS value in dB ?
#160;#160; 20 x log10(Measured/Reference0_dB)#160;
or 10 x log10(Measured/Reference0_dB)#160; ??
Im just physics student and im new in DSP,
so pleaz no angree about simple or stuppid questions.
Any examples and hints welcomed.
Many Tnx in advance.
Alf
RMS is used in audio to express the power. By analogy, some
manufacturers are using it to express the output or input voltage
of their equipments. But it doesn't change anything, the math is always
the same with the db, When you are talking about power, you have
10 * log (P1/P2). When talking about voltage or current, it become
20 * log (U1/U2) = 20 * log (I1/I2)
http://en.wikipedia.org/wiki/Decibel
The 0 db of an audio equipment is the maximum level it can handle at a
given rate of distortion, and with a given and constant waveform or
noise.
With the analog electronic, your equipment will be able to handle
higher values of the input signal during a short period of time (in
some cases even much higher values). This is what we call the headroom.
It can be expressed by the measure of the musical power, it is the
same issue than with the measure of the rms or sinus power, you have to
know the exact condition of the measure in order to be able to
interpret it.
In other words, the specifications must tell you enough in order to be
able to reproduce exactly the same measurements and all the described
measurements. If it is not the case, they are just bullshit.
Another issue is that it is no normalised way to measure and express
the specifications of an audio equipment. Each manufacturer is using its
own measure protocol. So, it can be difficult to compare them on the
paper. And many specification sheets are just bullshit because they
doesn't tell enough about the conditions of the measurements.
With a digital signal, you will get no headroom at all. The maximum is
when all the bits are to 1. If you add something, the bit number
doesn't change and you will get a wrong result.
It is one point on which jack with its floating point approach is
better. You can do calculations inside jack that will be outside the
scope of the sound card but valid inside jack. With a floating point
approach, you can define the 0 db to be somewhere on the middle, and do
calculations with a good approximation, calculations that would be
impossible in practice with an integer based system (because of the
added complexity to take the errors in account). Of course, you
will still have to insure that the d/a converters of the sound card will
handle the result of your calculation.
Re: [LAD] [Jack-Devel] JACK and RT cgroups
Le Thu, 16 Dec 2010 20:01:46 +0100, Dhaval Giani dhaval.gi...@gmail.com a écrit : On Thu, Dec 16, 2010 at 7:53 PM, Dominique Michel dominique.mic...@vtxnet.ch wrote: Le Wed, 15 Dec 2010 20:07:37 +0100, Dhaval Giani dhaval.gi...@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
Re: [LAD] envy24control, resp. it's successor
On Mon, 13 Sep 2010 17:36:11 -0700 Niels Mayer nielsma...@gmail.com wrote: On Mon, Sep 13, 2010 at 2:25 PM, Ralf Mardorf ralf.mard...@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). Niels http://nielsmayer.com Hi, ICE1724 based sound cards share a lot of code in common with ICE1712 cards. Would it be possible to adapt envy24control in order to work with those cards, or to make one envy24htcontrol ? I am not a C/C++ developer myself, so I cannot contribute code for this work, but I own an audiophile 192 and can help with testing. Dominique --- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Audio2MIDI algorithms
It was a previous discussion Musescore music trainer?, about polyphonic audio to MIDI recognition. I found a windows program that claim to archive good results : TallStick TS-AudioToMIDI On this webpage : http://tallstick.com/webhelp/algorithm.htm, they wrote some interesting claims : - They (3 of the 4 algorithms) all are based on the set of oscillator circuits named sensors. Each sensor gets wave signal as input and produces some reply. Sensor's reply is a value proportional to the amplitude of component with frequency about equal to sensor's resonance one. This is what I call filtre en peigne in french. Comb filter. Each teeth of the comb will test for one frequency. - After sensor's output is multiplied on correspond Equalizer values, it arrives on Spectrum Window. All these methods analyze spectrum data at each instant of time from left to right (from low to high pitches). When spectral maximum is detected it assumed to be fundamental frequency of note. This assumption is tested by comparing spectra to Harmonic model setting. After this, if assumed note is greater than Threshold value then note accepts, otherwise rejects. If note is accepted, all it's spectral components are subtracted from corresponding components of whole spectra. This show that the whole algorithm is more complex than a simple recursive filtering. They take in account the spectra of the music. You can (and must) assign the instruments that play the music, before to made the conversion. Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Musescore music trainer?
Le Fri, 12 Nov 2010 00:54:58 -0500, Tim E. Real termt...@rogers.com a écrit : On November 11, 2010 11:06:10 pm Dominique Michel wrote: Le Thu, 11 Nov 2010 16:43:41 -0300, Camilo Polymeris cpolyme...@gmail.com a écrit : For me, a stand alone pitch detection application would be better : audio in - pitch detect - midi out You plug the instrument into the audio in, connect the midi out to any midi in in qjackctl, and it is just to play some melody. Ciao, Dominique There is aubionotes (http://aubio.org/aubionotes.html), which claims to do exactly what you want. Don't know how well, though. I am trying to connect it to PianoBooster, to see if that could be a solution. WaoN could also be an option, I'll try that next. Eventually, I'd like an integrated app. Greetings, Camilo Thanks for the tip ! Ok. If someone is interested: I can report that aubionotes works quite well for the samples I tried (brass mostly, all monophonic). WaoN is similar, maybe even better, but doesn't work realtime, it handles pre-recorded samples, only. Same thing here. I think that it must use some kind of fft. The problem with fft and realtime is not the processing power but the time it take before you get a sufficient amount of samples in order to be able to run the fft. Ciao, Dominique Exactly. I was going to start a thread asking about this. Mind if I pitch in? Difference between lowest note on a guitar and next note is very small, requiring large number of FFT bins. (If you play a flute, you're lucky.) You can put a crappy time domain style pitch shifter ahead of the converter to reduce this. (A good freq domain PS may have more latency.) It's fun. With practice a normal guitar becomes a piano etc... I've seen polyphonic products advertised claiming zero or near zero latency. How do they do it? I don't know. If you take a guitar synthesizer, it have a polyphonic mic, that is one mic per cord (similar to a simple humbucking per note). They certainly make 6 monophonic note extractions. Guitar mics take in account only the vertical movements of the cords, the output signal is the derivative of this movement. Also, the harmonic content of a guitar note is not constant. During the attack, the value of the fundamental is the most important signal in the note, but during the sustain, the value of the fundamental decrease very fast and the second harmonic become the highest tone in the note. It is even more complicated when the cord touch the frets because you will get false maximums of the signal. You can also get hum with a simple humbucking, and you will get saturation with a double humbucking. I've used FFT, but when told of this delay problem, my friend keeps telling me no, use Laplace transforms. When I studied them (looong ago), I could not fully understand how to apply the knowledge. Is there a Laplace library out there? I am not sure, but the FFT is a particular case of the bipolar Laplace transformation, so I don't think than the necessary time to get enough samples in order to get a reliable result would be better. The worst case scenario depend on the lowest note you will able take in account. Wavelets? I studied those as well, but my meagre brain could not cement. If it is what I call filtre en peigne in French (comb filter), it can be an alternative. It is DSP algorythms for them, but I don't know if it is something for a PC processor. To catch the higher notes first, how about n FFTs with n samplers driven by n separate even-tempered clocks, where n is the desired number of notes? For ex. 3 octaves, 36 FFTs. I forget why, but I think that didn't work out. I think the pesky relation giving the delay kept getting in the way. You increase the sample rate and you just end up increasing the delay because you need more freq bins for the same given resolution. The delay is really governed by the smallest difference in notes you want to detect. In guitar's case, I found it just passes as acceptable. Tim. The fastest algorithm would be to find the maximums of the signal. The time between 2 consecutive maximums = the period of the note. The delay would not be constant, but it would not exceed 1+1/2 periods of the note in the worst case. In practice, it would be something between 1 and 1+1/4 periods of the note in most (all?) cases. This will be very easy with an instrument like a flute, but much more difficult with an instrument like a guitar, because you will have to take in account the false maximums possibility (when you play very hard on the cords or when you have a not so good guitar) and the sustain of the note. Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What do you do for a living?
Le Tue, 09 Nov 2010 19:17:24 -0800, Kris C cp...@yahoo.com a écrit : Hi all, Yeah, I'd like to work for Google, but who doesn't right? :) -Kris I am a 50 years old guy. When I was young, my mother was working as a secretary in a middle size family company, my father was dead in a car crash. And I was studying in a good private school here in Switzerland. But capitalism is capitalism, and today, only the ones working at the direction of a medium or big company can afford to pay for a good private school for their children. So, I don't regret my life, just enough work in order to pay the bills AND to have fun the rest of the time. Of all countries where I was during my trips, only one is different, its Cuba. This is the only country I know where it is not much differences between the richest and the poorest. And, year after year, according to Amnesty International, Cuba is the country in the whole America, from the Canada to Argentina, to do respect the most the human rights. It is also the country of the whole world where it is the most musicians per inhabitants, and they do makes outstanding musics. (For the record, Plato wanted to get rid of all the poets from his republic.) And no, I am not a software engineer, I am administrator of a few FOS projects, one of them is audio related. For living, I was engineer in electronic and electricity, especially all the analog electronic from vacuum tubes amplifiers to DSP. Now, I repair Caterpillar like machines. It doesn't take the head, I move a lot more, and I am in much better form. Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Musescore music trainer?
Le Thu, 11 Nov 2010 16:43:41 -0300, Camilo Polymeris cpolyme...@gmail.com a écrit : For me, a stand alone pitch detection application would be better : audio in - pitch detect - midi out You plug the instrument into the audio in, connect the midi out to any midi in in qjackctl, and it is just to play some melody. Ciao, Dominique There is aubionotes (http://aubio.org/aubionotes.html), which claims to do exactly what you want. Don't know how well, though. I am trying to connect it to PianoBooster, to see if that could be a solution. WaoN could also be an option, I'll try that next. Eventually, I'd like an integrated app. Greetings, Camilo Thanks for the tip ! Ok. If someone is interested: I can report that aubionotes works quite well for the samples I tried (brass mostly, all monophonic). WaoN is similar, maybe even better, but doesn't work realtime, it handles pre-recorded samples, only. Same thing here. I think that it must use some kind of fft. The problem with fft and realtime is not the processing power but the time it take before you get a sufficient amount of samples in order to be able to run the fft. Ciao, Dominique -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Musescore music trainer?
Le Wed, 10 Nov 2010 13:36:21 -0300, Camilo Polymeris cpolyme...@gmail.com a écrit : maybe http://pianobooster.sourceforge.net/ is what you want ? Very interesting. Will try it as soon as possible. Piano/MIDI only input, right? But maybe support for other instruments and pitch detection can be added. Thanks, Camilo For me, a stand alone pitch detection application would be better : audio in - pitch detect - midi out You plug the instrument into the audio in, connect the midi out to any midi in in qjackctl, and it is just to play some melody. Ciao, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN][Request] AlsaPlayer-0.99.81 is out !
Le Mon, 8 Nov 2010 12:23:12 +1100, Erik de Castro Lopo mle...@mega-nerd.com a écrit : Dominique Michel wrote: While it's a nice player, it has some serious audio quality issues. - Resampling 44.1 - 48 kHz (for jack) sounds horrible... Which resampler are you using? I am not sure, I can only understand very obvious things in c and c++. It look like to be into app/AlsaNode.cpp and the different output plugins (into output/*). For what I understand, the output plugins are just sending the sampling rate to AlsaNode.cpp, but after that, I am sure of anything. Fons seam to know the internal of the AlsaPlayer. - The sndfile input plugin reduces everything to 16 bits. This is really absurd, even if your files and your sound card are 24 bit you only get 16. Floating point wav files apparently aren't read at all (they load but produce silence when played). This is not a problem with libsndfile itself, but rather with the way you are using libsndfile. Again, for what I understand, libsoundfile is used into input/sndfile/sndfile_engine.c It is an input plugin. They are other input plugins: audiofile, cdda, flac, mad, mikmod, mpg123, vorbis and wav. All of this could be solved by using a good resampler lib, and making the internal format floating point rather than short. There is little reason not to use 32 bit float as an internal format, even on things like netbooks and tablets. I am just an admin and don't have the knowledge to make the needed code. Anybody that can contribute such a great feature for AP will be welcomed. If you are interested, please take contact with me, on this list or privately. Who are the developers of this project or has it been abandoned? Well, it is no active developer at that time. It was written by Andy Lo A Foe, his last working commit is from December 2003. After that, this project has been dead until I take over its administration in January 2007. I applied important patches they was sleeping on the mailing list, and done a new release the 1 February. After this release, madej was doing a very great job with a new gtk2 interface in 2007, but he was not willing to incorporate the team. It is some other developers, but now one is active for now. It was a discussion into 2007 about sockets for AP, but no work was done in that direction. Now, as I see the current state of AP, it seam more important to me to first fix the current issues, like the resampling quality and a more up-to-date jack code. After that, I am open to anything that will be a good move. The core of AP was not modified from 2003, at the exception of bugfixes. For this release, it is more bugfixes that peoples external to the AP team send me. That can explain why the internal audio format is still using integer instead of float. It will be very great if someone was willing to share its knowledge and improve this player. It have some outstanding features like the ability to do varispeed in a linear fashion from 10 times backwards to 10 time forward. Mplayer do have a similar function. I was talking about libsamplerate because, according to Fons, this lib can do the resampling and the varispeed. I don't know with libsndfile. Dominique Erik -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] [ANN][Request] AlsaPlayer-0.99.81 is out !
I send the following to the LAA : This is a bug fix release. A big thanks to all that send fixes to me, without you, the AlsaPlayer will not be living. See the ChangeLog for the details and the names of the contributors : http://alsaplayer.svn.sourceforge.net/viewvc/alsaplayer/trunk/alsaplayer/ChangeLog?revision=1345view=markup I will also stress you to contribute to the AlsaPlayer. At least 2 things need to be fixed. The first one is the jack output plugin that is using deprecated functions. The second one is the resampling. For that, libsamplerate will give a better quality. Enjoy the AlsaPlayer, # # # # # To quote Fons (he do have a better English than mine) : While it's a nice player, it has some serious audio quality issues. - Resampling 44.1 - 48 kHz (for jack) sounds horrible... - The sndfile input plugin reduces everything to 16 bits. This is really absurd, even if your files and your sound card are 24 bit you only get 16. Floating point wav files apparently aren't read at all (they load but produce silence when played). All of this could be solved by using a good resampler lib, and making the internal format floating point rather than short. # # # # # This change can be made using libsample rate. This is a must have feature for me, and it must be implemented before any other change because it will ease further development (it is a lot of free re-usable audio code in float). I am just an admin and don't have the knowledge to make the needed code. Anybody that can contribute such a great feature for AP will be welcomed. If you are interested, please take contact with me, on this list or privately. Ciao, Dominique Michel -- We have the heroes we deserve. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] RT
Le Fri, 25 Apr 2008 12:35:43 -0400, Joshua D. Boyd [EMAIL PROTECTED] a écrit : Is it possible to configure a system (included changes to programs) so that nothing can interfere with a few RT threads? I have an audio and video thread in a program, and they are running as SCHED_FIFO, but so many things can interfere with those two threads, such as USB plugs/unplugs, cron log rotations, disk access (PIO flash disk), ssh logins, etc. I really would like to shore up performance here. I am not using Ingo's RT patches, but I still see people talking about turning off things like cron and server processes to prevent xruns when using Ingo's RT patches. While I have turned off cron, turning off sshd and the web server aren't options. I want to instead somehow make sure that neither can every interfere with the AV threads, even if it means that SSH and web traffic are extremely slow. http://proaudio.tuxfamily.org/wiki/index.php?title=Realtime_%28RT%29_Kernel#IRQ_tweaking You must use the rtirq package. It is a boot script that use chrt to fix the priorities for different IRQ. The trick is to setup the highest priority to the rtc (the system will hang otherwise), followed by the sound, followed by the other pieces of hardware. If your distribution doesn't provide this package: http://www.rncbc.org/jack/ Cheers, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Secret Rabbit Code : New release imminent
Le Sat, 8 Mar 2008 15:35:47 +1100, Erik de Castro Lopo [EMAIL PROTECTED] a écrit : Hi all, After a very long time indeed, I am in the final stages of a new release for Secret Rabbit Code aka libsamplerate. The big news is that I found a way to drastically improve the quality of the SFC_SINC_MEDIUM_QUALITY and SRC_SINC_BEST_QUALITY converters. For more info on that, see this blog entry: http://www.mega-nerd.com/erikd/Blog/CodeHacking/SecretRabbitCode/progress.html I'm aiming for the new release to happen next weekend. Cheers, Erik Thank you for such a great work! Dominique -- Dominique Michel Mes 3 projets préférés auxquels je contribue: * FVWM-Crystal, le bureau basé sur FVWM: http://fvwm-crystal.org * AlsaPlayer, le lecteur audio avec contrôle de vitesse en continu: www.alsaplayer.org * L'overlay pour la MAO sous gentoo: http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] midi player for jack ?
Le Thu, 7 Feb 2008 00:29:06 +0100, Fons Adriaensen [EMAIL PROTECTED] a écrit : Salve, Is there anything like pmidi for midi-over-jack (i.e. a command line midi file player) ? Ciao, I don't know pmidi, but I get better result with timidity++ as with my audigy with huge soundfonts. And I only have a P4 at 2GHz. With recent timidity version (2.13.2 here), you can start timidity in server mode for jack: timidity -iA -B2,8 -Oj -EFreverb=0 The result will be: TiMidity starting in ALSA server mode Opening sequencer port: 129:0 129:1 129:2 129:3 But timidity audio output will appear in the jack panel of qjackctl. For other options (command line player, ...), see timidity -h. Best, Dominique -- Dominique Michel Mes 3 projets préférés auxquels je contribue: * FVWM-Crystal, le bureau basé sur FVWM: http://fvwm-crystal.org * AlsaPlayer, le lecteur audio avec contrôle de vitesse en continu: www.alsaplayer.org * L'overlay pour la MAO sous gentoo: http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] VroomBox
Le Tue, 9 Oct 2007 19:22:42 +0300, Juhana Sadeharju [EMAIL PROTECTED] a écrit : Is this patented? I could not find. http://www.vroombox.com/vroombox/ I don't know details of them, but I come up with the idea some years ago --- as to exists as an open source, free Linux software, naturally. I even mailed to Blaupunkt and asked if it is ok to send them suggestions. Because I received no reply, I did not send anything to them about my invention. Juhana Will the next model change the smell too? Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] AlsaPlayer 0.99.80-rc4 is out!
This is a bugfix and feature improvement release. Madej added a song title in the title bar option. Several bugs was fixed. Among them, libmad was fixed in configure and a possible horrible crash when upgrading from a gtk1 AlsaPlayer version was fixed. Every user is encouraged to upgrade. Please contribute with bug reports and artwork. See http://www.alsaplayer.org/artwork.php3 for existing artworks. Discussion about which artwork(s) to include with the next stable release will be done on the mailing list. See the website for details: http://www.alsaplayer.org Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] Re: Direct Stream Digital / Pulse Density Modulation musing/questions
Le Tue, 25 Sep 2007 19:31:52 +0200, Fons Adriaensen [EMAIL PROTECTED] a écrit : On Tue, Sep 25, 2007 at 10:50:48AM -0600, Bearcat M. Sandor wrote: When i went down my local (ok, only) studio to have some LPs transferred to CD the studio owner and i were talking about this very subject. He told me that one day he bought a new mixer to replace his aging one. He set it next to his old one and got it ready. The phone rang. He spent the next few hours experimenting with it, and was happy with the differences it made in the sound he was trying to achieve. However, he had forgotten to turn it on. I'm sure this isn't the only such story out there. If a person can fool themselves into believing that such a piece of equipment is even functioning, how much difference can it make? As a matter of fact, i think he returned the mixer and stuck with his old one. A nice variation on this theme occured years ago at an AES conference. The speaker wanted to demonstrate that 'digital' sound was crap, by using the familiar 'push down the extended arm' test. Test persons listening to analog sound could easily resist, while they lost all force when listening to a digital recording. What the speaker didn't know was that the PA system used to play the tracks was fully digital... Years later the same person was promoting DSD against PCM, by the way... Ciao, Haha! It remain me some test that was done in Switzerland in the sixties (or something like that) by the national TV. Test persons was listening to 2 sorts of sounds: normal stereo, and mono with different tone settings on the left and right channel. Of course, the conclusion was that it was not possible to determinate for sure if a sound was stereo or mono. It is why we have in Switzerland only monophonic sound on the TV. Some movies are transmitted with bicanal sound: it is 2 time mono, one time in one language and one time with the original language. You can choose the language. Most users are not even aware of that possibility. lol... Personally, I don't like it. I prefer very much a good stereo sound in the original language (with some kind of text if it is a language that I don't understand) like on the Swedish TV. For that PCM-DSD stuff. I prefer PCM because we can archive a good sound quality with a much lower bandwitch. DSD was fine at the beginning of digital recording because it was nothing else (for what I know), but for today's professional audio, DSD is a waste of resources because of the huge needed bandwitch. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] Circular Reasoning
Le Fri, 31 Aug 2007 14:59:55 +0200, Jens M Andreasen [EMAIL PROTECTED] a écrit : Late one friday afternoon, a sound-engineer was sitting in his chair admiring a brand new pair of flat frequency response monitors. He then observed the following: For two frequencies represented by sine-waves and an octave apart to have the same relative loudness, the higher octave will need to have its amplitude adjusted to half of that of the lower octave.[1] Both frequencies will then force a membrane to travel the same distance within a given timeframe - the higher will go half as far but twice as often than the lower - and they will also both have the same speed or steepness at the zero-crossing. Surprisingly, the lower frequency consumes four times as much energy than the higher[2], although it is apparently not doing any more actual work. Therefore, it is a better excersize to take a walk around the block, rather than running around in small circles. QED cheers! // Jens M Andreasen Ahahah! It is why I go to my job with my bicycle. It take a longer time, but it is a much better exercise as to do the same with my car. And I do not contaminate the air of others with my bicycle. It is a word for that: respect, the only only remedy against the destruction of the environment, the racism and their consequences. Cheers, Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] [ANN] New AlsaPlayer releases
AlsaPlayer license is changed to GPL-v3. In consequence, all the AlsaPlayer related packages are updated. AlsaPlayer is a new type of PCM player. It is heavily multi-threaded and tries to excercise the ALSA library and driver quite a bit. It has some very interesting features unique to Linux/Unix players. http://www.alsaplayer.org http://sourceforge.net/project/showfiles.php?group_id=249 # AlsaPlayer-0.99.80-rc2 is the new GTK2 release of this versatile audio player. A lot of debugging and improvements has been made on the GTK2 interface (and under the surface too). The GTK1 interface was removed in the process. GTK2 is now fully internationalized and a few languages are provided. Extended header support in mp3 file is added, so the console will not complain anymore about this, and the user's experience is improved. Every user is encouraged to upgrade AlsaPlayer and help with development, bug reports, feature requests, translations... We need your help with a few things: * Bug reports * Feature requests * Artwork contributions * Translation for more languages and improvement of the existing ones. * FftSope-1.0.6 FftScope is a nice visualization plugin for AlsaPlayer. It is now under GPL-v3 and the GTK1 interface is removed from the package. The GTK2 interface provide the same level of functionality as before. * python-alsaplayer-0.3.1 These are python bindings for the AlsaPlayer library. The intent is to provide a set of bindings that closely mirror the C library, leaving more complex functionality for purely python modules. This release update the license to GPL-v3 or later. This is the initial release of this midi input plugin for alsaplayer. It is derived from Tuukka Toivonen's TiMidity and reflects the work of a number of other people (see AUTHORS). Compile and install it in alsaplayer's input/ plugin directory, install a soundfont, then you can play midi files with alsaplayer. I hope you will enjoy those releases and AlsaPlayer's very nice GTK2 interface! -- Dominique Michel -- N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me parvenir. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Re: [LAD] simulating analog audio devices part II
Le Mon, 18 Jun 2007 21:59:25 +0200, Giuseppe Zompatori [EMAIL PROTECTED] a écrit : In general there seem to be a lot of problems in simulating the power section of push-pull NFB enabled amps in LTSpice... the NFB starts oscillating producing really high frequencies even at modest volumes eventually inflating the sim duration to infinity... garanted that's also what happen in reality but only when the power section is severely distorting... The problem here is not the simulator but the valve models. Most of them don't modelise the grid current or have a very very poor approximation, they have a poor approximation of Ig2, they don't modelise the variation of the valves characteristics when Ug2 is changing, and they have a very poor approximation of the variation of the valves characteristics when Ig2 is changing. According to the data sheet, some tetrodes can get 2 watts on the command grid at full output. That implies huge grid current. At the same time, we will get huge Ig2 variations and Ug2 will drop (even with fixed Ug2 bias) because the voltage delivered by the power supply will drop at full output (around 100V drop on some peavey amplifiers!!! The saturation we can heard is for the half the saturation in the main transformer not in the amplifier or output transformer!!!). So, in short, don't expect a good or reliable result of a push-pull class B guitar amplifier with so limited valves model. And to simulate the whole amplifier is a must do, but without more reliable models, it doesn't make sens to try to optimize something with a simulation for that kind of electronics. In consequence, for me, and as long at we don't have better valves models, practical experiences are everything. Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] [ANN] AlsaPlayer 0.99.80-rc1 and FftScope 1.0.5
I am very proud to announce 2 new releases: alsaplayer-0.99.80-rc1 and fftscope-1.0.5 The main added feature in those 2 packages is a new GTK2 interface. I must thank Madej. He done most of the job and is still working to improve it. Alsaplayer-0.99.80-rc1 -- AlsaPlayer is a new type of PCM player. It is heavily multi-threaded and tries to excercise the ALSA library and driver quite a bit. It has some very interesting features unique to Linux/Unix players. This is a major feature enhancement release. The player has now a fully working GTK2 interface. It includes the same functionality as the GTK1 interface and some new functions. The playlist window has been completely rewritten and is inside the main window. The scopes plugins have been migrated too. A lot of debugging has been made. Every user is encouraged to upgrade AlsaPlayer and use the GTK2 interface. We need your help with a few things: * Bug reports * Feature requests * Artwork contributions fftscope 1.0.5 -- Fftscope is a nice fft scope plugin for Alsaplayer. It is now 2 versions of this scope in the package: one with GTK1 interface, the other with GTK2 interface. This is a major feature enhancement release Enjoy those 2 new releases! --- http://www.alsaplayer.org/ http://sourceforge.net/project/showfiles.php?group_id=249 Dominique ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] [ANN] Alsaplayer 0.99.79 and fftscope 1.0.4 released
Alsaplayer 0.99.79 -- AlsaPlayer is a new type of PCM player. It is heavily multi-threaded and tries to excercise the ALSA library and driver quite a bit. It has some very interesting features unique to Linux/Unix players. This is a feature enhancement and minor bugfix release. New features: Basic keyboard navigation and loop inside a selection have been added. Bugfix: A missing include was added; this make at Alsaplayer will compile on never gcc and non gcc compilers. ChangeLog from the last release: * Updated config.guess and config.sub with latest savannah version. * Added missing include in app/CorePlayer so it will compile with never gcc and non gcc compilers. Thanks to Debian for this fix. * Applied Debian patch from Viktor Radnai and Paul Brossier. Add basic keyboard navigation (skip, pause, etc.), loop mode (looping inside a selection), pressing play button or key during playback return to the beginning of the song, speed changes one musical semitone a time using the keyboard (handy for changing the key the song is played back in). * Added keyboard shortcuts for speed +/- 1 comma (useful to tune the player when playing some musical instrument at the same time). * Updated the man page with those keyboard bindings. fftscope 1.0.4 -- Fftscope is a nice fft scope plugin for Alsaplayer. This release is a major bugfix release and each user is encouraged to upgrade. Alsaplayer was crashing at exit time when this scope was installed but not running. A missing test in the quit function was added. The compilation flags in Makefile.am was fixed. Enjoy those 2 new releases! --- http://www.alsaplayer.org/ http://sourceforge.net/project/showfiles.php?group_id=249 Dominique -- Dominique Michel -- N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me parvenir. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
[LAD] [ANN] alsaplayer-0.99.78 released
AlsaPlayer is a new type of PCM player. It is heavily multi-threaded and tries to excercise the ALSA library and driver quite a bit. It has some very interesting features unique to Linux/Unix players. This is a feature enhancement and minor bugfix release. Support for FLAC-1.3 and 1.4 is added. A desktop file is included. See the ChangeLog for the details. http://www.alsaplayer.org/main.php3 http://sourceforge.net/projects/alsaplayer/ I will also remember you at a new and usable python binding module is available in a separate package. Those bindings cover the functionality in control.h. More functionality can be added it you want, but this level of functionality must be what you are looking for in most cases. Help will be very welcomed to continue to improve Alsaplayer. The 3 main areas of work will be: 1) Rework the core functionality: * Adding TCP-based control module in parallel with unix-socket based one. * Separating libalsaplayer and checking for crossplatform-readiness. * Separating all interfaces (the main questionable thing). 2) Add more input plugins. 3) Do a modern interface. At least 3 possibilities are possible: * With the existing experimental GTK2 interface. * With the existing experimental QT interface. * With the python bindings. If you want to participate, please take contact on the alsaplayer-devel list: http://www.alsaplayer.org/lists.php3 Cheers, -- Dominique Michel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
