Re: [LAD] So what do you think sucks about Linux audio ?
On Sat, Feb 9, 2013 at 2:29 AM, John Rigg lad...@jrigg.co.uk wrote: To be fair I wasn't really slagging off Windows and Mac users. Most pro audio engineers are using those after all. I'm just bemused by the attitude that audio processing tools should be anything more than that. Pretty pictures and dumbed down control ranges don't help me make better mixes, they just get in my way. But why instantly dumbed down? Or are the generic LADSPA controls so intellectual? I think beautifully down interface adds to the inspiration as opposed to stuff that all looks like coding examples. -- Louigi Verona http://www.louigiverona.ru/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] jackdbus eating 100% cpu after a while
Hi, I was a long term jackd1 user and my first action on a new linux installation (mostly using Ubuntu) was normally to remove pulseaudio as it was badly configured and/or buggy. Things have changed and I really started to like PA for everyday stuff. And then jackdbus came along which together with the device reservation API and the jackd sinks promised to make using these two things together more easy. This mostly works fine, except for the device reservation bug in PA which is easy to work around though: - Make sure no audio process is actively using the soundcard you want jackd to use - Run pulseaudio -k - Run jack_control start I have noticed some issues with jackdbus though: a] jack_control start sometimes doesn't work at all after the first time it failed to aquire the device. A killall -9 jackdbus is in order to restore it b] after some hours of operation jackdbus starts to eat 100% cpu on two of my four cores. Are these known issues? I use Ubuntu 12.10 and jackd: fps@mango 12:08:21 .../Games/Xonotic/ $ jackd -v jackdmp 1.9.9 [...] How to diagnose the 100% cpu thing more closely? The ~.log/jack/jackdbus.log shows nothing suspicious. Thanks and regards, Flo -- Florian Paul Schmidt http://fps.io ___ 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 ?
On Sat, Feb 09, 2013 at 12:03:41PM +0300, Louigi Verona wrote: On Sat, Feb 9, 2013 at 2:29 AM, John Rigg lad...@jrigg.co.uk wrote: To be fair I wasn't really slagging off Windows and Mac users. Most pro audio engineers are using those after all. I'm just bemused by the attitude that audio processing tools should be anything more than that. Pretty pictures and dumbed down control ranges don't help me make better mixes, they just get in my way. But why instantly dumbed down? Or are the generic LADSPA controls so intellectual? I think beautifully down interface adds to the inspiration as opposed to stuff that all looks like coding examples. By dumbed down I mean restricted in a way which may result in inexperienced users making fewer mistakes, but will also inconvenience more advanced users. An example of this would be a high mid EQ that won't sweep above 8kHz. What if I need to EQ 12kHz? There's some excuse for this kind of thing on analogue hardware, as component cost has to be kept down, but in a plugin it's totally unnecessary. Another pet peeve is lack of a text entry field on controls, as it makes it difficult to set a parameter to an exact amount. Even worse are detented controls. What if I need an intermediate setting? The reason for detents on analogue hardware is for repeatability of settings, but it's totally redundant in software, unless the developer has neglected to provide text entry! I will stress that I'm talking about audio engineering tools, not music creation software here. I do appreciate that users of the latter have very different requirements. John ___ 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 ?
Right, I hear you John. But I did look at pro mastering software on Windows, I don't remember any unnecessary restrictions. My message would that I oppose this sort of a sweeping judgment of a whole audio platform. There might be some concrete examples, sure, but if you mean that in general all or most software on Windows is restricted in such a manner, I personally would want some proof. For instance, what restrictions of that sort can you name in iZotope Ozone? L.V. ___ 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 ?
On Sat, Feb 9, 2013 at 8:38 PM, Dominique Michel dominique.mic...@vtxnet.ch wrote: 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. To be fair, real-time pitch to midi is not a linux audio problem but a general DSP problem that so far as I know, is far from solved on any platform. If your solution works as well as you say then you need to put it in a product and market it asap! This is something that I know people have sought for a long time. Even purpose built high-end hardware units, like the Axon series coupled with something like a Godin Synth Access guitar, have limitations and require the player to adapt to those limitations. ___ 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 ?
On Sat, Feb 09, 2013 at 11:16:48AM +, John Rigg wrote: By dumbed down I mean restricted in a way which may result in inexperienced users making fewer mistakes, but will also inconvenience more advanced users. An example of this would be a high mid EQ that won't sweep above 8kHz. What if I need to EQ 12kHz? There's some excuse for this kind of thing on analogue hardware, as component cost has to be kept down, but in a plugin it's totally unnecessary. I've seen some EQ plugins that actually become unstable near FS/2. And even some where the author didn't bother to limit the F range in that case - move the slider too far with some others at the right value and watch the smoke from your tweeters. Lots of plugins are written by people who apparently never have used real audio engineering gear ever, and don't bother to test their code or even understand what exactly it will do. Some ten years ago someone wrote an 'RMS' routine as part of a compressor plugin. It does a sliding window calculation over 256 samples. You can find verbatim copies of it in at least 5 other dynamics plugins and also in 'VU' meters (which are not even supposed to use RMS). While it's not entirely wrong, the result is that the compressor (or whatever) will be completely insensitive to level variations at some frequencies. For example, at 48 or 44.1 kHz, any modulation by around 90 Hz (or integer multiples) will be completely ignored. Five millisecs attack time ? Forget it - you get some attack time that depends on input content in a completely haphazard way. And of course the same lenght is used at whatever sample rate. The result is then presented as an 'RMS' compressor... Another pet peeve is lack of a text entry field on controls, as it makes it difficult to set a parameter to an exact amount. Even worse are detented controls. What if I need an intermediate setting? The reason for detents on analogue hardware is for repeatability of settings, but it's totally redundant in software, unless the developer has neglected to provide text entry! I generally dislike text input on audio engineering tools. The controls should have sufficient resolution. More often than not the author just accepts the display resolution (e.g. standard toolkit sliders), and if these don't have fixed sizes you don't even have repeatable settings. For EQ frequencies I usually have steps 1/3 or 1/6 octave depending on filter type, with finer steps availiable using a modifier key. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ 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 ?
Am 09.02.2013 12:38, schrieb Dominique Michel: Is is a few applications that claim to be able to do that. By example guitarixhttp://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. To be clear, we never claim to be able to do that! That is a quote from a user, not from us (guitarix developers). This audi2midi converter was never mean to do what you expected, it was ever mean as a Band in the Box experience. I had a lot of fun with it by driving (qsynth) some percussion, or a Bass, . . with it, when I play alone guitar. However, this module is removed (from the releases) since a year or so, ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] jackdbus eating 100% cpu after a while
Hi James, On 02/09/2013 01:11 PM, James Stone wrote: Hi Flo, I am also running Ubuntu 12.10 and using jackdbus. It is really nice for things like playing along to youtube videos.. On my computer, I noticed that jack does have a tendency to lockup after a while when jackdbus is running. I had the feeling that it might be something to do with latency, as I found it is impossible to start jack at very low latencies with jackdbus running. I was using 128 samples which seemed to be OK, but at that latency, the lockups occurred after some time. I tried increasing latency to 256 samples/44.1k. Following this, it seems to operate fine (at least I have had no more dropouts), but it is all a bit fiddly to get it to work properly, and I would probably disable pulse if I wanted to do serious recording etc without the mixing capabilities that jackdbus adds.. James I use very large period sizes, 1024 or even 2048. The problem of jackd starting to eat 100% cpu occurs usually when I'm done with my current work (recording something or fiddling around) and just leave it running idly. Then when I return to my computer after a few hours jackd sits there happily eating cpu. It has the side effect of heating my room, but heating with electricity is expensive and thus I'd rather avoid it ;D Have fun, Flo -- Florian Paul Schmidt http://fps.io ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] jackdbus eating 100% cpu after a while
On Sat, Feb 09, 2013 at 01:24:22PM +0100, Florian Paul Schmidt wrote: I use very large period sizes, 1024 or even 2048. The problem of jackd starting to eat 100% cpu occurs usually when I'm done with my current work (recording something or fiddling around) and just leave it running idly. This sounds a bit like denormals. Which CPU? Just to be sure. Cheers -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ 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 ?
On Sat, Feb 09, 2013 at 02:20:58PM +0300, Louigi Verona wrote: Right, I hear you John. But I did look at pro mastering software on Windows, I don't remember any unnecessary restrictions. My message would that I oppose this sort of a sweeping judgment of a whole audio platform. There might be some concrete examples, sure, but if you mean that in general all or most software on Windows is restricted in such a manner, I personally would want some proof. There's a misunderstanding here. I'm criticising plugin design choices which make my job difficult, regardless of platform. That includes Linux. John ___ 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 ?
On Sat, Feb 9, 2013 at 11:16 AM, John Rigg lad...@jrigg.co.uk wrote: I will stress that I'm talking about audio engineering tools, not music creation software here. I do appreciate that users of the latter have very different requirements. I was reading your post, about to vocalize the counter-argument, but you're right, they're two entirely different things. I'd like to add to my list of what don't we have, music creation software. I mean, dumbed down controls: where every settings sounds *ok*, and some sound amazing. No amplitude spikes just cause you adjust a control to a non-integer multiple of the blah blah, and upon filing a bug report recieving you should know better than to do that. Live musicians can't deal with the chance the software will do something crazy. More (LV2 instrument effect) software with dumbed down controls :) -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] LV2 Synths Hosts : MIDI binding
Hey all! I have a simple enough question, but I don't know the best practice for solving it, so figured I'd ask. There's an LV2 synth running in a LV2 host. The synth exposes its operation trough control ports. Option 1: The plugin can bind incoming MIDI events to these control ports values, allowing standard MIDI maps to be made for the synth. Use cases include using the synth on another machine with the same hardware: easy operation, layout identical to before. Downside: these MIDI binding values are hard coded in the plugin, and can't be changed. Also the host may update the control port (which has been effected by the MIDI stream) and causes a parameter jump. Option 2: The host has to implement its own form of binding the MIDI events to the control ports. Downsides: the plugin has no control over what causes what effect, so no standardized maps can be made. Application specific MIDI mapping... which is nasty. I think the safe option is number 2, each application sorts this thing out itself, and the user has to map the same synth per host. The MIDI mapping situation on Windows and MacOS is terrible (IMO), with various different software re-map features like Novation Automap, and Bores midi translator just getting in the way even more. Can anybody see a solution to using the same MIDI map for the same instrument in different software, without hard-coding it in the plugin? Or another solution? -Harry ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Synths Hosts : MIDI binding
On Sun, 2013-02-10 at 01:01 +, Harry van Haaren wrote: Hey all! I have a simple enough question, but I don't know the best practice for solving it, so figured I'd ask. There's an LV2 synth running in a LV2 host. The synth exposes its operation trough control ports. Option 1: The plugin can bind incoming MIDI events to these control ports values, allowing standard MIDI maps to be made for the synth. Use cases include using the synth on another machine with the same hardware: easy operation, layout identical to before. Downside: these MIDI binding values are hard coded in the plugin, and can't be changed. Also the host may update the control port (which has been effected by the MIDI stream) and causes a parameter jump. Option 2: The host has to implement its own form of binding the MIDI events to the control ports. Downsides: the plugin has no control over what causes what effect, so no standardized maps can be made. Application specific MIDI mapping... which is nasty. Both are possible depending on the details of the plugin. Plugins can not change their own control inputs, so if you have ControlPorts then the host must do it. As things move to event-based control this will go away, but that's perhaps a discussion for another time. Note that in a plugin that supports CC directly it's not necessarily true that the CC numbers are hard coded. You could use other events to configure them dynamically. With this stuff, unfortunately, the answer is almost always both, and then some. Some plugins are dumb, some are pretty clever, and some are even a full-blown host with its own dynamic MIDI binding implementation. I think the safe option is number 2, each application sorts this thing out itself, and the user has to map the same synth per host. The MIDI mapping situation on Windows and MacOS is terrible (IMO), with various different software re-map features like Novation Automap, and Bores midi translator just getting in the way even more. Can anybody see a solution to using the same MIDI map for the same instrument in different software, without hard-coding it in the plugin? The LV2 midi extension includes a vocabulary that can be used to describe MIDI bindings in a standard way. For this we may need a new Bindings class or something, but the guts of describing controllers and associating ports with bindings are already there. No particularly deep problems here that I can see if you're just interested in the MIDI bindings for control ports case, it just needs establishing, which would indeed be a nice thing to do. An idiot-proof API in lilv would probably make it much nicer for hosts to implement. (Interestingly this is very preset-like in many ways) I'm assuming you mean just for LV2, if you mean broader scope then of course there are a whole slew of additional questions. Cheers, -dr signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] simple silence detection tool
I'm looking for a simple tool where I can point it at an http audio stream, define a number of seconds to detect silence and exit with a non-zero status if silence is detected. It seems like this should be easy but I've been search high and low for such a utility and nothing simple exists. Unfortunately I'm not much of a developer, but this doesn't seem like it would be that difficult. Maybe it's harder than I think, hence no tool that I can find. Thanks -jeremy ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
